Chromium Blog: 11月 2019

Intent to Explain: Demystifying the Blink Shipping Process

2019年11月12日火曜日

If you’re a standards-curious web developer, you may have wondered how features get added to browsers, or even how the Chrome team decides what they will work on. You probably also have, at least at some point, thought to yourself “I have this urgent problem but I’ll have to work around it for the foreseeable future, because browsers are just too slow to bring in changes”. You may have even added some expletives when no one was around.
If that description sounds accurate, this is the post for you! This post will describe the Blink process, how browser engineers (both inside and outside of Google) use it in order to ship features in Chromium, what considerations are taken when deciding to ship a new feature, as well as some considerations that impact what features get worked on, and how you can play a role in all of this! Project goals The Chromium project is the open source project on which Chrome is built, and on which other browsers are also based: Samsung Internet, Opera, Brave, Vivaldi, and last (to join the project) but not least, Microsoft Edge. The project enables all those different browsers to share a single implementation of the web platform, and at the same time, keep their unique characteristics and focus.
Blink is the rendering engine used by Chromium. It is the part of the project that descends from WebKit (the rendering engine Safari uses), and which is mostly (but not exclusively) responsible for the Chromium’s Web Platform implementation. The goal of Chromium and Blink inside it is to continuously improve the web platform as a whole.
How does Blink improve the web platform?

By improving its predictability through testing and infrastructure, making sure developers have to spend less of their time tackling browser-specific issues and more of their time… well, developing.

By removing user hostile features, features that increase the platform’s complexity or make its implementations less secure.

By adding platform capabilities that enable web developers to innovate and create web experiences that meet and exceed their users’ expectations and needs.

If we want the web to thrive in the long term, we need to make sure that our users consider it safe and pleasant to use, and that it supports all the capabilities developers need in order to easily make their users (and businesses) are happy.
Any improvement to the platform needs to take backwards compatibility and cross-browser interoperability into account. There’s a lot of web content out there that will never change. The risk of breaking some of it needs to be weighed against the user benefits of shipping that new feature or removing that risky old one. Similarly, in cases where Blink is the first engine to ship a feature or to remove it, we should make sure other browser vendors can follow. We do that by ensuring shipped features designs are widely reviewed, and have specifications and tests to guide future implementers.
The Chromium project is rather large, and is being worked on by many different entities. Therefore it needs to control which features get shipped, while being even-handed in that decision process. We achieve that through a simple process that guides contributors as they evolve the platform to ensure maximum long-term compatibility and interoperability. What features get worked on? Chromium is an open source project that’s being worked on by over 2000 engineers from ~55 different organizations. Of course, Google is responsible for the bulk of Chromium - 92% of commits to the project (data) come from Google, although about 20% of contributors are not Google-affiliated.

With a project of this magnitude, each of the involved companies and contributors are naturally pushing their own slightly different agenda and priorities. Even within Google’s Chrome team there are multiple ways to prioritize which problems are most urgent to tackle and solve. One area that is consistent, is that we work with the ecosystem and developer partners to understand and address their needs. We do that by creating compatibility dashboards, collaborating with frameworks, and observing development patterns in the wild.
The MDN survey is a great example of how the ecosystem can help shape the priorities that a browser vendor has. We’re still in the process of analyzing the results, but it was clear that compatibility is a top priority for developers and we will commit to keep improving on it. We also plan to create more ways to gather structured data on developer needs and hardships.
As you can imagine, with all these priorities from different contributors, it's important for us to be clear about how a feature goes from inception to shipping.

So, what are the typical phases of creating a new web platform feature and shipping it in Chromium?
The very first step before getting started would be to figure out what we need to be working on and which user or developer problems are the most burning ones. That is typically done by talking to partners, looking at current development patterns and consulting with web developers and framework authors to get a better understanding of what the platform can do better to address their and their users’ needs. Once we know which problem we want to tackle, we can start incubating it! What does “incubating” mean?
Over the years, we found that the best way to design and prototype a new platform feature is through incubation - getting a strong grasp of the use cases a feature is trying to solve as a first step, and then rapidly iterating over the design in a public forum that includes browser engineers and domain experts. Only once we are certain that a feature solves important use-cases and have high confidence that it solves it the right way, we bring that feature to an official track at a Standard Development Organization, such as a W3C Working Group, the WHATWG, or TC39.
Not all incubations turn up to be standards though. Some incubations fail and some prototypes never make it out to the hands of users. That is perfectly fine and by design. The web platform cannot afford features that don’t solve real user or developer problems to creep in, and we want to make sure those features never make it to be a permanent part of the platform. Step 1 - Initial research At this phase, we establish a better understanding of the problem space, by gathering up the specific use-cases we want our future solution to tackle and the constraints under which the solution must operate.
At the end of that phase, engineers are expected to publish an explainer that outlines the above, and maybe have a very rough sketch of what a solution may look like. The explainer is published in a relevant public forum (e.g. the WICG discourse) in order to solicit feedback from the web community at large. Such feedback can include missed-out use-cases, further constraints that can impact the design, or simply statements of support for solving the problem.
It’s important at this stage to focus on the problem, and not over-index on any one possible solution - and this is one of the places we haven’t always been perfect. Step 2 - Design & Prototype Now that we have better grip of the problems we’re trying to solve and the constraints in which we operate, we can start designing the feature and what it may look like. Ideally, the design team would include browser engineers from interested vendors as well as problem space experts from the web developer or framework developer community.
Once we have an initial rough design, it might be a good idea to start building and committing code (behind a flag and turned off by default) in order to better understand the solution’s feasibility and complexity.
That’s when engineers should send out an “Intent to Prototype” email to blink-dev (previously, “Intent to Implement”), in order to notify the relevant code owners that work is underway in that area. Note that such an intent doesn’t mean that the feature is shipping soon, or that it will ship at all for that matter. It just means that this is a problem space that’s being explored, and code is landing to that end.
That’s also a good point in time to make sure the feature will get a wider review, by filing for a TAG review. Step 3 - Experiment & iterate Once code starts to land behind a flag, it’s a good time for interested web developers to start playing around with the solution by turning on the feature flag and testing it out. Feedback on the initial implementation is critical in order to make sure the eventual design would work well for developers and users alike. For some features, such experimentation is enough for developers to get a good handle on what’s the solution looks like, and how well it addresses the problem.
In other cases, it’s critical to gather data from the field regarding the solution, to see how well it works in broader deployment to fulfill user’s needs, or get a better understanding of its performance characteristics at scale. Step 3.5 - Origin Trial In those cases, a browser engineer can request an Origin Trial (by sending out an Intent to Experiment email), which enables interested developers to test the feature out in broader deployment to users who have not turned on the feature flag. Once an Origin Trial is in place, developers can register for the trial, and enable the feature (in production) for their domains. That enables them to gather data on the user impact of the feature, and report it back to the design team, confirming or refuting their assumptions regarding the solution’s viability.
Note that an Origin Trial is a temporary experiment, and there’s a good chance that the feature will significantly change before it will be enabled by default, or even that the effort will be dropped altogether. Developers interested in participating should take that into account, and not rely on the feature being available to their users beyond the scope of the trial. Step 4 - ship it! Once the previous steps were completed with success and the team believes the feature is ready to be turned on by default, that’s when they can submit an Intent to Ship.
That’s a part of the process that’s a bit more strict.
In order to ship a feature by default, engineers need approval for the feature to ship from 3 API owners.
What’s an “API owner”? API owners are a set of trusted Chromium engineers, who are responsible for enforcing the Blink process guiding principles. Each feature we’re trying to ship has some user and developer benefits, otherwise we probably wouldn’t be working on it. Shipping new features can introduce interoperability risks, if other browsers don’t follow us. The API owners are tasked with applying our compatibility and interoperability principles and help evaluate each shipping feature with regards to its risk/benefit tradeoff. They then provide their approval on “Intent to Ship” threads for new shipping features, if they think the benefits outweigh the risks. Those approvals are provided in the form of “LGTM” (“Looks Good To Me”) replies on intent threads.
Note that LGTMs are not required for Intent to Prototype. For an Intent to Experiment, approval from a single API owner is sufficient, as the risk they pose is fairly contained.
As part of the “Intent to Ship” request, chromium engineers need to provide clear signals regarding the risk and benefit tradeoff of the feature.

The feature needs to have a solid specification and a comprehensive cross-browser test suite in order to minimize interoperability risk.

Signals from other browser vendors as well as from wide review forums (such as the TAG) are taken into account, alongside signals from the web developer community and partners who are planning to use the feature.

If the feature went through an Origin Trial, a report outlining the results is also important to better understand the benefits.

Note that the fact that an “intent to ship” is sent indicates the team’s estimate of the feature being ready to ship, but it does not necessarily mean that the feature will ship shortly, or at all.
Some features take a long time to go through the intent process, in order to prove that the risk they pose is low enough to justify shipping. Others get held up addressing feedback from other vendors or from wide-review forums.
In other (rare) cases, features can be rejected by the API owners, and their proponents then need to look for alternative ways to resolve the problem, which won’t hit the same concerns that got their initial intent rejected. Removing features Finally, while adding new feature certainly grabs most people’s attention, an equally important part of the intent process is to deprecate and remove legacy web platform features. In those cases, the main risk is breaking existing content, and the benefits are typically around improving user’s security, privacy and performance. The project’s willingness to take some compatibility risk and remove features is critical to our risk/benefit calculus also when launching features first - if we got it wrong and late feedback causes us to change course, we typically can figure out a path to deprecate those features to get us back on track to interoperability. Summary The Chromium’s project goal is to make sure the web platform remains a healthy and successful platform. For that, we believe the platform needs to make significant progress in the face of shifting developer and user expectations, as well as adapt to the changing market forces and constraints. At the same time, we need that progress to be done in a responsible manner both inside the Chromium project and when it comes to our collaboration with the wider ecosystem.
The Blink process’ role is to keep the balance between those different requirements, and to help ensure the web is a thriving platform for generations to come.

Posted by Yoav Weiss, Wrangler of processes and Advocate of developers.

Chrome Dev Summit 2019: Elevating the Web Together

2019年11月11日月曜日

As the largest open ecosystem in history, the Web is a tremendous utility, with more than 1.5B active websites on the Internet today, serving nearly 4.5B web users across the world. This kind of diversity (geography, device, content, and more) can only be facilitated by the open web platform.
Users uniquely experience the Web as one as they navigate from site to site, and thus the responsibility is with all of us to work on delivering quality experiences that reach all.
At this year’s Chrome Developer Summit (CDS), we are focusing on giving developers the capabilities to reach the bar that our users demand. To help further foster the diversity and capability for web developers, we’ve been working closely with the ecosystem to make enhancements to the web platform, improve developer experience, and make meaningful updates to the browser itself.

Enhancing the versatility of the Web
Our vision is to make loading disappear for all our users. At I/O this year, we previewed Portals, which allows developers to create seamless experiences by pre-rendering content and optionally embedding it in the page to change the way users navigate across the web. We’re pleased to see the new style navigation from early partners like Fandango have been testing on their site already. Portals is available behind the chrome://flags/#enable-portals flag for developers to experiment with.

At CDS this year, we’re previewing Web Bundles, an infrastructural API that will allow developers to distribute their web content across any format - email, FTP, or even USB, without any compromises. Not only does this unlock delivery of web content at lightning fast speeds, it will also allow for peer-to-peer distribution even when users are offline. In the future, APIs like Background Periodic Sync and Content Indexing will allow developers to proactively cache and surface relevant web content for people even if they’re not on an active internet connection. Web Bundles is now available behind the experimental flag, and the other two are now available as origin trials.
Consumption of web content has never been more diverse; while the rise of mobile-first in developing markets has been well documented, we’re now seeing an increase in cross-device computing with the youth across the globe. We’re committed to making the platform powerful enough for developers to create amazing modern experiences that users expect while taking advantage of the frictionless of the web. By focusing our efforts on enabling fully capable web applications, we’ve been working to bring many primitives to the platform, including:

SMS Receiver, allowing web apps to retrieve two-factor SMS messages.

Contact Picker, which will allow people to share web content to their contact lists, bringing social media and communication capabilities to web apps.

Native File System API, enables web apps to read or save changes directly to files and folders on the user's device. This allows developers to build powerful web apps that interact with files on the user's local device, like IDEs, photo and video editors, text editors, and more.

There’s a lot more that we’re working on in this space and we can’t wait to see what you build with these capabilities. You can read all about our latest work in our blog on supporting new web experiences.

Enabling developer success no matter the framework or CMS
As web developers, we’re on a collective journey providing people their best, unique web experience. This collective responsibility makes accurate, actionable data on the health of the web increasingly important.
CDS gives us a checkpoint to see how we are doing and have a discussion on where we go next. We use the HTTP Archive to see how the web is built and the Chrome User Experience Report to see how it is experienced. Over the past year, we’re seeing a positive growth in the percentage of sites with fast First Contentful Paint and fast First Input Delay, our core metrics for loading and interactivity.
Measuring user experience quality is multi-faceted, today we introduced two new metrics to give developers a holistic view of how their sites are performing. Largest Contentful Paint (how quickly users see the most meaningful page content) and Cumulative Layout Shift (how stable a page feels).
Now, data is great, but insights that lead to fixes and improvements are better. We often get asked “What do I do with this information?” We’ve collaborated with many experts from the community on The Web Almanac, to give developers a holistic view of the health of the web. We launched over 17 chapters today and we’re excited to continue to identify and share more such insights.

Developers work incredibly hard to move their performance metrics in the right direction, so we are looking at ways to reward developers for going the extra mile. Today we are sharing some early explorations which surface speed signals in Chrome’s UI.

Frameworks, libraries and CMS’es form a critical part of the developer ecosystem and we’re keen to support them on their journey of creating instant and seamless for their users. Earlier this year we created Lighthouse Stack Packs for WordPress and React to support their developer ecosystems in build fast and reliable sites, and today we’ve increased the coverage include Angular, AMP as well as the ecommerce CMS, Magento, bring more actionable insights to developers irrespective of the tools developers use.
We’ve been excited to see that the Framework Fund has supported a number of meaningful projects that make it easier to hit the performance bars by default, and we’re looking forward to seeing more projects being funded this year.
Finally, we have launched Lighthouse CI to make sure that developers are given insights for each pull request. Developers can quickly hook up Lighthouse CI to their build pipeline to get a rich diff of the changes that they made and the impact it had on the quality of their site.

Making the browser work for you
We believe the web is for everyone, no matter their device type, internet speed or purchasing power. To help ensure the platform remains accessible to all, we’re investing in performance and memory improvements to the browser, including bringing new features like Image Lazy Loading that is now going to be available to Chrome Lite users by default, and Paint Holding, shipping soon in Chrome.
The web needs to be a safe and trustworthy place for everyone. Furthering our initiatives around HTTPS encryption, we began working with the community to start blocking all mixed content - insecure HTTP subresources on HTTPS pages - by default, and also experimenting with DNS over HTTPS, which offers better security and privacy by encrypting the traffic between the browser and DNS provider
We are also following up on our I/O promise to make our existing third-party cookie controls more visible. Starting with the Chrome M79 Beta, we’re experimenting with a toggle for controlling third-party cookies on the Incognito New Tab Page. We are also working on redesigning our settings pages to make access to this control easier in regular mode. And finally, apart from continuing to make progress to improve the existing cookies infrastructure, we’re also continuing to develop our Privacy Sandbox, a secure environment for content that also protects user privacy.
We want to thank the entire web community for their continued investment in a platform that is so impactful to so many people around the world. We believe it is our collective responsibility to elevate the web experience for every user and in that spirit, let's celebrate the 'We' in Web.
Posted by Dion Almaer, Web Developer Ecosystem

Moving towards a faster web

2019年11月11日月曜日

Speed has been one of Chrome’s core principles since the beginning - we’re constantly working to give users an experience that is instant as they browse the web. That said, we have all visited web pages we thought would load fast, only to be met by an experience that could have been better. We think the web can do better and want to help users understand when a site may load slowly, while rewarding sites delivering fast experiences.
In the future, Chrome may identify sites that typically load fast or slow for users with clear badging. This may take a number of forms and we plan to experiment with different options, to determine which provides the most value to our users.
Badging is intended to identify when sites are authored in a way that makes them slow generally, looking at historical load latencies. Further along, we may expand this to include identifying when a page is likely to be slow for a user based on their device and network conditions.
Our early explorations will look at a number of Chrome surfaces, including the loading screen (splash screen), loading progress bar and context-menu for links. The latter could enable insight into typical site speeds so you’re aware before you navigate.

Our plan to identify sites that are fast or slow will take place in gradual steps, based on increasingly stringent criteria. Our long-term goal is to define badging for high-quality experiences, which may include signals beyond just speed.
We are building out speed badging in close collaboration with other teams exploring labelling the quality of experiences at Google. We believe this will ensure that if you are optimizing your site to be fast, your site will not be inconsistently badged from one surface to another.
We are being very mindful with our approach to setting the bar for what is considered a good user experience and hope to land on something that is practically achievable by all developers. We will publish updates to this plan as we approach future releases, but don’t wait to optimize your site. A number of resources are available for learning what opportunities are available to improve your site speed. To evaluate performance, check:

PageSpeed Insights, an online tool that shows speed field data for your site, alongside suggestions for common optimizations to improve it.

Lighthouse, a lab tool providing personalized advice on how to improve your website across performance and other best practices.

To learn about performance best practices, check web.dev/fast - our learning platform with guides and codelabs on how to get your pages loading instantly.
We are excited to reward you for your work and give our users more transparency into typical site performance. We hope this effort will encourage more sites on the open web to provide the best possible experiences to all users.
Posted by Addy Osmani, Ben Greenstein and Bryan McQuade from the Chrome team

Making new experiences possible on the web

2019年11月11日月曜日

The web that we know today has come a long way from its humble beginnings as simple interlinked documents; today it powers a huge number of rich services and applications.

Content consumption is at the heart of the web, however there are many tasks that people need to turn to native applications to accomplish. Our vision is that applications shouldn't require heavyweight downloads or updates. The web should be more than enough for any user experience.

What Makes the Web Special for Apps

The greatest strength of the web is the incredible ease of access. Content and functionality is immediately available to users without any installs or setup required. We have all enjoyed this ease of access for shopping, email, banking, connecting with friends, and much more, but there is no reason this ease of access can’t apply to practically any use case. Because of the hardened sandbox and progressive permission model of the web, users don’t have to worry about clicking a link the same way they need to worry about downloading an executable.

The URL and linkability supercharge the distribution and virality of applications and makes collaboration easy. With a web application, users can share a link through any channel and the receiving user can click that string to quickly access the application. Users sharing the link don’t need to worry about whether the receiving user has the application installed or if their OS even supports it; the application is simply there and works everywhere. This ease of sharing and ease of access also dramatically widens the user acquisition funnel.

The web is a truly open platform. You control the availability of your site and no one can block your users from accessing it. The web is also built on open standards and every major renderer is open source. This means you aren’t dependent on any one specific company or OS and as new devices & platforms emerge the web will be supported there as well.

Chromium's 3 Piece solution

Today, anyone with a browser can collaborate on complex designs, create CAD drawings, edit documents, watch endless videos, and play tons of games, but there are still gap compared to what native applications can do. These are tasks like complex editing, creativity tools, and advanced device communication. Chromium is pursuing WebAssembly, Advanced Capabilities, and Progressive Web Apps in order to close them.

WebAssembly: Powerful Portability

Developers should be able to performantly bring existing investments in low-level languages like C++ to the web. The need for reliable, high performance for demanding workloads has also been a reason some apps avoid the web. Our answer to both these needs is WebAssembly.

WebAssembly uses a combination of low-level primitives and strong static typing to deliver predictable performance for low-level code, avoiding the performance cliffs and GC pauses. With additions like threads and SIMD, applications can make full use of modern, multi-core processors with advanced instruction sets.

Because WebAssembly is a compilation target, it allows developers to bring their existing applications and libraries to the web without rewriting in JavaScript. The Emscripten toolchain offers a lot of porting support and has let applications such as AutoCAD & Sketchup come to the web, and the results are amazing. The web's advantages of easy sharing and collaboration, applied to advanced productivity apps, open up whole new ways of working.

Advanced Capabilities: Securely granting access to powerful capabilities

For Web Apps to be as useful as native apps, they need to have access to the same device capabilities that native apps enjoy, like file system access, NFC communication, contact picker, geolocation, and many more.

Exposing these capabilities in a user-understandable and safe way is a big challenge, but one that Chromium is committed to. The web works through a progressive permission model, where each capability is granted as needed through user permission and is as limited in scope as possible. This is in contrast to native apps, which can get full access to your file system, while web apps can only save back to folders and files you have explicitly shared and given write permission for. For capabilities like USB or Bluetooth, we allow the user to choose the specific device they would like to share.

Progressive Web Apps: The native feel with web superpowers

Web apps need to behave like other applications and be in the places users expect them to be in order to earn a central place in our lives. Our answer is Progressive Web Apps (PWAs).

PWAs can be installed and behave like any native app. Once installed they are launched from the same place as other installed apps and open in their own window. We are also working with Microsoft and Chrome OS to provide deeper integration such as appropriate storage management attribution. PWAs can even be listed in the Microsoft and Samsung Galaxy store and can utilize Trusted Web Activities to be in the Play store.

Here’s to an ever advancing web

The web has come a long way since its original inception. The web is a truly unique platform with properties that benefit users and developers. Through the enabling technologies of WebAssembly, powerful capabilities, and PWAs, developers will be able to create any experience their users need and utilize the web’s amazing properties.

Posted by Thomas Nattestad, Product Manager, Awesome web experiences

Chromium Blog

Intent to Explain: Demystifying the Blink Shipping Process

Chrome Dev Summit 2019: Elevating the Web Together

Moving towards a faster web

Making new experiences possible on the web

ラベル

Archive

Feed