Planet Chromium

November 13, 2019

Chromium Blog

Chrome Dev Summit 2019: Elevating the Web Together



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.
Fandango Portals demo

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

by Chromium Blog (noreply@blogger.com) at November 13, 2019 12:01 PM

Chrome Dev Summit is now open for registration!


We’re excited to announce that registration for the seventh Chrome Dev Summit is now open and you can request your invite here today! During the Summit, we will share our vision for and updates on our work towards moving the web platform forward and of course, have a bit of fun. ‘Cuz what’s Chrome Dev Summit, without some fun? 



Event details:
Date: Nov 11-12, 2019
Venue: Yerba Buena Center for the Arts in San Francisco, CA

What’s happening?

Over the two days, we will focus on the latest best practices, tools and updates coming to the web platform and give developers a chance to hear directly from the Chrome product engineering teams. 


Similar to last year, we’ll have a single track of content in one hall so everyone can enjoy all the sessions and have meaningful discussions. We’re also bringing back the Forum where you’ll be able to enjoy demos of the latest web technologies and developer tools as well as engage with the Chrome team as well as folks from the community.


We’ll be adding more details on the event site, as we move closer to the event, so watch out for more in the coming weeks and months.

Can’t attend in person? 

As always, we want to ensure that Chrome Dev Summit stays inclusive and exciting for everyone, regardless of whether you’re joining us in person or online. We’ll be livestreaming the entire two days of content for our online attendees and will also include some exciting livestream-only content. 


Sign up here so we can send you updates on the livestream and other related info around the event.


The Chrome team is committed to making the Web the best platform to give everyone in the world universal access to content and apps. We want to make it easier for developers to bring best-in-class content and experiences to their users, by making it more powerful and by reducing the cost of development. And we hope to do this as responsible citizens of the community, working with others to uphold our principles of promoting the open web.


We look forward to seeing you in San Francisco for yet another awesome Chrome Dev Summit!



Posted by Paul Kinlan, Content-Herder-and-Speaker-Wrangler-in-Chief

by Chromium Blog (noreply@blogger.com) at November 13, 2019 11:54 AM

November 12, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The Dev channel has been updated to 80.0.3964.0 for Windows, Mac and Linux

A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Srinivas Sista Google Chrome

by Srinivas Sista (noreply@blogger.com) at November 12, 2019 01:18 PM

Chromium Blog

Intent to Explain: Demystifying the Blink Shipping Process

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.

by Chromium Blog (noreply@blogger.com) at November 12, 2019 11:02 AM

November 11, 2019

Chromium Blog

Making new experiences possible on the web

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

by Chromium Blog (noreply@blogger.com) at November 11, 2019 03:44 PM

Moving towards a faster web

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

by Chromium Blog (noreply@blogger.com) at November 11, 2019 10:31 AM

November 08, 2019

Google Chrome Releases

Stable Channel Update for Chrome OS

The Stable channel is being updated to 78.0.3904.92 (Platform version: 12371.89.0) for most Chrome OS devices. This build contains a number of bug fixes and security updates. Changes can be viewed hereSystems will be receiving updates over the next several days.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using 'Report an issue...' in the Chrome menu (3 vertical dots in the upper right corner of the browser).
Geo Hsu



Google ChromeOS

by Geo Hsu (noreply@blogger.com) at November 08, 2019 03:03 PM

Dev Channel Update for Desktop

The Dev channel has been updated to 80.0.3962.2 for Windows, Mac and Linux

A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Srinivas Sista Google Chrome

by Srinivas Sista (noreply@blogger.com) at November 08, 2019 01:56 PM

November 07, 2019

Google Chrome Releases

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 79 (79.0.3945.29) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at November 07, 2019 03:30 PM

Beta Channel Update for Desktop

The beta channel has been updated to 79.0.3904.29 for Windows, Mac, and Linux.


A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Prudhvikumar Bommana
Google Chrome

by Krishna Govind (noreply@blogger.com) at November 07, 2019 10:53 AM

November 06, 2019

Google Chrome Releases

Chrome for Android Update

Hi, everyone! We've just released Chrome 78 (78.0.3904.96) for Android: it'll become available on Google Play over the next few weeks.

This release contains the following features, as well as stability and performance improvements:
  • Dark theme for Chrome menus, settings, and surfaces. Find it in Settings > Themes.
You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at November 06, 2019 03:58 PM

Stable Channel Update for Desktop

The stable channel has been updated to 78.0.3904.97 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.


Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

This update includes 4 security fixes. Please see the Chrome Security Page for more information.

We would like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

As usual, our ongoing internal security work was responsible for a wide range of fixes:
  • [1021723] Various fixes from internal audits, fuzzing and other initiatives



A list of all changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at November 06, 2019 11:56 AM

November 04, 2019

Google Chrome Releases

Stable Channel Update for Chrome OS

The Stable channel is being updated to 77.0.3865.120 (Platform version: 12371.89.0) for most Chrome OS devices. This build contains a number of bug fixes and security updates. Changes can be viewed hereSystems will be receiving updates over the next several days.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using 'Report an issue...' in the Chrome menu (3 vertical dots in the upper right corner of the browser).

Daniel GagnonGoogle Chrome OS

by Daniel Gagnon (noreply@blogger.com) at November 04, 2019 10:00 AM

November 01, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The Dev channel has been updated to 80.0.3955.4 for Windows, Mac and Linux

A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Srinivas Sista Google Chrome

by Srinivas Sista (noreply@blogger.com) at November 01, 2019 01:39 PM

Chromium Blog

Chrome 79 Beta: Virtual Reality Comes to the Web

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 79 is beta as of October 31, 2019.

Virtual Reality Comes to the Web

The WebXR Device API is shipping in Chrome. Developers can now create immersive experiences for smartphones and head-mounted displays. Other browsers will be supporting these specs soon, including Firefox Reality, Oculus Browser, Edge and Magic Leap's Helio browser, among others.

This launch sets the foundation for immersive features to come, such as supporting augmented reality, tools, and expanding the real-world understanding of immersive experiences. Many experiences can be enhanced with immersive functionality. Examples include games, home buying, viewing products in your home before buying them and more. To get started with virtual reality and the new API, read Virtual reality comes to the web.


Origin Trials

This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

Support for rendersubtree Attribute

Adds the rendersubtree attribute to all HTML elements, which locks a DOM element for display. When rendersubtree is set to "invisible", the element's content is not drawn or hit-tested, allowing for rendering optimizations. The rendersubtree "activatable" token allows the browser to remove the invisible attribute, rendering the content, and making it visible.

Wake Lock API based on Promises

Adds an update of the Wake Lock API that introduce promises and wake lock types. The Wake Lock API brought a standard, secure, and safe way to prevent some device features such as the screen or CPU cycles from going into power saving state. This update addresses some of the shortcomings of the older API which was limited to screen Wake Lock and didn't address certain security and privacy issues.

Other Features in this Release

Adaptive Icon Display for Installed PWAs on Android

Android Oreo introduced adaptive icons, which enforced the same shape for all icons on the home screen and in the launcher. Before android O icons could be any shape and there was no background behind each icon. For example, gmail was rectangular, and Play was a triangle. Consequently, such icons were placed in a white circle. With adaptive icon display, Android will automatically mask irregularly shaped icons to fit properly.

Autofocus Support for any Focusable HTML/SVG Element

Adds the autofocus attribute to any focusable HTML or SVG element. The autofocus was previously supported for a limited number of HTML elements, and there were elements which could receive focus but didn't support the autofocus attribute. This feature fixes the inconsistencies.

Compute img/video Aspect Ratio from Width Or Height HTML Attributes

The aspect ratio of an image is now computed so that it can be used for sizing an image using CSS before it loads. This avoids unnecessary relayouts when the image loads.

font-optical-sizing

The font-optical-sizing property
automatically sets the font size to the opsz - optical sizing axis of variable fonts that support optical sizing. This improves styling and legibility of fonts depending on font size because the font chooses a glyph shape that works optimally at the given font size. For example, the glyph contrast is improved in fonts in heading sizes when compared to the same font at body text size.

list-style-type: <string>

Allows a stylesheet to use an arbitrary character for the list style marker. Examples include "-", "+", "★" and "▸". Since CSS Level 2, list-style-type has supported keywords like disc or decimal to define the appearance of the list item marker.
Without this, developers are often forced to hide the real marker and insert the arbitrary marker using a ::before pseudo element via the content property. Unfortunately, the fake marker won't be nicely positioned by list-style-position.

Reject Worklet.addModule() with a More Specific Error

When Worklet.addModule() fails, a promise rejects with a more specific error object than it did previously. Worklet.addModule() can fail for various reasons, including, for example, network errors and syntax errors. Before this change, Worklet.addModule() rejected with AbortError regardless of the actual cause. That made it difficult for developers to debug worklets. After this change, Worklet.addModule() rejects with a clearer error such as SyntaxError.

Retrieve a Service Worker Object Corresponding to a Worker Itself

A service worker can now get its ServiceWorker object with self.serviceWorker in a service worker script and its current state with self.serviceWorker.state. A service worker instance previously had no way to get its current lifecycle state. This removes the need for the hack wherein the current lifecycle state is tracked with a global variable, a method that is error prone and doesn't correctly capture waiting periods.

Stop Evaluating Script Elements Moved Between Documents During Fetching

Chrome no longer evaluates scripts or fire error and load events if <script> elements are moved between documents during fetching. Script elements can still be moved between documents, but they won't be executed. This prevents possible security bugs caused by exploitation of <script> elements moved between documents.

Deprecations, and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.

-webkit-appearance Keywords for Arbitrary Elements

Changes -webkit-appearance keywords to work only with specific element types. If a keyword is applied to a non-supported element, the element takes the default appearance.

by Chromium Blog (noreply@blogger.com) at November 01, 2019 09:19 AM

October 31, 2019

Google Chrome Releases

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 79 (79.0.3945.18) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at October 31, 2019 03:30 PM

Stable Channel Update for Desktop

The stable channel has been updated to 78.0.3904.87 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.


Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

This update includes 2 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.

[$7500][1013868] High CVE-2019-13721: Use-after-free in PDFium. Reported by banananapenguin on 2019-10-12
[$TBD][1019226] High CVE-2019-13720: Use-after-free in audio. Reported by Anton Ivanov and Alexey Kulaev at Kaspersky Labs on 2019-10-29

Google is aware of reports that an exploit for CVE-2019-13720 exists in the wild.

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.



A list of all changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at October 31, 2019 02:08 PM

Beta Channel Update for Desktop

The Chrome team is excited to announce the promotion of Chrome 79 to the beta channel for Windows, Mac and Linux. Chrome 79.0.3945.16 contains our usual under-the-hood performance and stability tweaks, but there are also some cool new features to explore - please head to the Chromium blog to learn more!



A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at October 31, 2019 01:50 PM

October 30, 2019

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 78.0.3904.85 for Windows, Mac, and Linux.


A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at October 30, 2019 03:42 PM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 79.0.3945.13 (Platform version: 12607.9.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. Changes can be viewed here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser).

Cindy Bayless
Google Chrome OS

by Cindy Bayless (noreply@blogger.com) at October 30, 2019 01:01 PM

October 29, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The Dev Channel has been updated to 79.0.3945.16 for Windows, Mac, and Linux.



A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Krishna Govind Google Chrome

by Krishna Govind (noreply@blogger.com) at October 29, 2019 05:15 PM

October 28, 2019

Chromium Blog

Addressing some misconceptions about our plans for improving the security of DNS

Whenever you type a URL into your browser (for example “redcross.org”), this information is sent to a domain name system (DNS) provider that converts that request into the unique numerical “IP address” (e.g. 162.6.217.119) that identifies websites on the Internet. Your browser then uses that numerical IP address to take you to the site you were looking for. Unfortunately, today the requests from your browser to the DNS provider are not encrypted (which makes you vulnerable to passive monitoring by strangers) nor authenticated (which makes you vulnerable to online attackers). This is especially true when you’re connected to public WiFi, for example at a cafe or airport, since anyone else using the network can see and track the websites you visit and maybe redirect your browser to a malicious website.

In September, we announced an experiment in Chrome to improve online privacy and security by enabling secure DNS connections with DNS-over-HTTPS (DoH) for users already using DNS providers that support it. DoH is being developed by the Internet standards community as a step toward better security and privacy by encrypting the traffic between your browser and your DNS provider. It improves privacy by removing one of the ways used by malicious actors to observe the browsing habits of other users on the same network. DoH is also a significant security improvement, as it helps stop man-in-the-middle attacks on DNS lookups. Many privacy-minded organizations, journalists, other browser providers and internet service providers (ISPs) agree that these changes will improve your privacy and security.

Unfortunately, there has been some misinformation and confusion about the goals of our approach and whether DoH will impact existing content controls offered by ISPs. The confusion comes from two particular claims and we want to address both.

The first claim is that Google is going to redirect user DNS traffic to Google's own DNS or another DoH-compliant DNS provider. That is incorrect. Because we believe in user choice and user control, we have no plans to force users to change their DNS provider. Today, there are many independent DNS providers, although ISPs serve approximately 97% of user DNS needs. As long as these service providers keep catering to user needs and concerns, it will remain a diverse ecosystem. We’re simply enabling support in Chrome for secure DoH connections if a user’s DNS provider of choice offers it. Chrome will check if the user’s DNS provider is among a list of participating DoH-compatible providers and if so, it will enable DoH. If the DNS provider is not on the list, Chrome won’t enable DoH and will continue to operate as it does today. As DoH adoption increases, we expect to see the number of DoH-enabled DNS providers grow.

The second claim we’ve seen is that the secure DoH connection will limit the family-safe content controls offered by some ISPs. In fact, any existing content controls of your DNS provider, including any protections for children, should remain active. DoH secures the URL data only while it’s in transit between your browser and the DNS provider, so your provider’s malware protection and parental control features will continue to work as they have in the past. As a proof point, CleanBrowsing offers the same parental control features on its DoH service as it does on its unencrypted service.

As we said last month, we’re taking an incremental approach with this experiment, and our current plan is to enable DoH support for just 1% of our users, provided that they are already using a DoH compliant DNS provider. This will allow Google and DoH providers to test the performance and reliability of DoH. We’ll also monitor feedback from our users and from other stakeholders, including ISPs. Most managed Chrome deployments such as schools and enterprises are excluded from the experiment by default. We also offer policies for administrators to control the feature. Finally, Chrome users may opt-out of the DoH experiment entirely by going to chrome://flags/#dns-over-https, starting in Chrome 79.

We are optimistic about the opportunities DoH offers for improving user privacy and security, but we also understand the importance of DNS and that there could be implementation concerns we haven’t foreseen. That’s why we plan to move carefully and transparently. We’re open to feedback and welcome constructive collaboration and engagement. We are committed to ensure that the deployment of DoH does not create unintended consequences and we will continue to work with stakeholders including ISPs, DNS providers, and Internet and child safety advocates as we make progress.


Posted by Kenji Baheux, Chrome Product Manager

by Chromium Blog (noreply@blogger.com) at October 28, 2019 12:35 PM

Developers: Get Ready for New SameSite=None; Secure Cookie Settings

UPDATE (10/28/2019): We've revised the 2nd and 3rd bullet points in the section "How to Prepare; Known Complexities" below.
In May, Chrome announced a secure-by-default model for cookies, enabled by a new cookie classification system (spec). This initiative is part of our ongoing effort to improve privacy and security across the web.
Chrome plans to implement the new model with Chrome 80 in February 2020. Mozilla and Microsoft have also indicated intent to implement the new model in Firefox and Edge, on their own timelines. While the Chrome changes are still a few months away, It’s important that developers who manage cookies assess their readiness today. This blog post outlines high level concepts; please see SameSite Cookies Explained on web.dev for developer guidance.


Understanding Cross-Site and Same-Site Cookie Context


Websites typically integrate external services for advertising, content recommendations, third party widgets, social embeds and other features. As you browse the web, these external services may store cookies in your browser and subsequently access those cookies to deliver personalized experiences or measure audience engagement. Every cookie has a domain associated with it. If the domain associated with a cookie matches an external service and not the website in the user’s address bar, this is considered a cross-site (or “third party”) context.

Less obvious cross-site use cases include situations where an entity that owns multiple websites uses a cookie across those properties. Although the same entity owns the cookie and the websites, this still counts as cross-site or “third party” context when the cookie’s domain does not match the site(s) from which the cookie is accessed.
When an external resource on a web page accesses a cookie that does not match the site domain, this is cross-site or “third-party” context.


In contrast, cookie access in a same-site (or “first party”) context occurs when a cookie’s domain matches the website domain in the user’s address bar. Same-site cookies are commonly used to keep people logged into individual websites, remember their preferences and support site analytics.

 
When a resource on a web page accesses a cookie that matches the site the user is visiting, this is same-site or “first party” context.


A New Model for Cookie Security and Transparency


Today, if a cookie is only intended to be accessed in a first party context, the developer has the option to apply one of two settings (SameSite=Lax or SameSite=Strict) to prevent external access. However, very few developers follow this recommended practice, leaving a large number of same-site cookies needlessly exposed to threats such as Cross-Site Request Forgery attacks.

To safeguard more websites and their users, the new secure-by-default model assumes all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections. This won’t mitigate all risks associated with cross-site access but it will provide protection against network attacks.

Beyond the immediate security benefits, the explicit declaration of cross-site cookies enables greater transparency and user choice. For example, browsers could offer users fine-grained controls to manage cookies that are only accessed by a single site separately from cookies accessed across multiple sites.


Chrome Enforcement Starting in February 2020


With Chrome 80 in February, Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. The Chrome Platform Status trackers for SameSite=None and Secure will continue to be updated with the latest launch information.

Mozilla has affirmed their support of the new cookie classification model with their intent to implement the SameSite=None; Secure requirements for cross-site cookies in Firefox. Microsoft recently announced plans to begin implementing the model starting as an experiment in Microsoft Edge 80.


How to Prepare; Known Complexities


If you manage cross-site cookies, you will need to apply the SameSite=None; Secure setting to those cookies. Implementation should be straightforward for most developers, but we strongly encourage you to begin testing now to identify complexities and special cases, such as the following:

  • Not all languages and libraries support the None value yet, requiring developers to set the cookie header directly. This Github repository provides instructions for implementing SameSite=None; Secure in a variety of languages, libraries and frameworks.
  • Some browsers, including some versions of Chrome, Safari and UC Browser, might handle the  None value in unintended ways, requiring developers to code exceptions for those clients. This includes Android WebViews powered by older versions of Chrome. Here’s a list of known incompatible clients.
  • App developers are advised to declare the appropriate SameSite cookie settings for Android WebViews based on versions of Chrome that are compatible with the  None value, both for cookies accessed via HTTP(S) headers and via Android WebView's CookieManager API, although the new model will not be enforced on Android WebView until later.
  • Enterprise IT administrators may need to implement special policies to temporarily revert Chrome Browser to legacy behavior if some services such as single sign-on or internal applications are not ready for the February launch.
  • If you have cookies that you access in both a first and third-party context, you might consider using separate cookies to get the security benefits of SameSite=Lax in the first-party context.
SameSite Cookies Explained offers specific guidance for the situations above, and channels for raising issues and questions.

To test the effect of the new Chrome behavior on your site or cookies you manage, you can go to chrome://flags in Chrome 76+ and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. In addition, these experiments will be automatically enabled for a subset of Chrome 79 Beta users. Some Beta users with the experiments enabled could experience incompatibility issues with services that do not yet support the new model; users can opt out of the Beta experiments by going to chrome://flags and disabling them.

If you manage cookies that are only accessed in a same-site context (same-site cookies) there is no required action on your part; Chrome will automatically prevent those cookies from being accessed by external entities, even if the SameSite attribute is missing or no value is set. However we strongly recommend you apply an appropriate SameSite value (Lax or Strict) and not rely on default browser behavior since not all browsers protect same-site cookies by default.

Finally, if you’re concerned about the readiness of vendors and others who provide services to your website, you can check for Developer Tools console warnings in Chrome 77+ when a page contains cross-site cookies that are missing the required settings:

A cookie associated with a cross-site resource at (cookie domain) was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.”Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.”" />Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.”" height="130" src="https://lh6.googleusercontent.com/AMjvE6tOlDJ8omG83qcir_OWvHdXTPM2PTFa_AVZa_2fbqBA85of3rU4-_d83Nm6m7W6ojc1gCGJkwsY3KljB2hHeCrcJH4H3G1ThES7wsceY34BrGF8a-srV0lKbsIjZBoi_Sl8" style="margin-left: 0px; margin-top: 0px;" title="" width="607" />

Some providers (including some Google services) will implement the necessary changes in the months leading up to Chrome 80 in February; you may wish to reach out to your partners to confirm their readiness.


Posted by Barb Palser, Chrome and Web Platform Partnerships

by Chromium Blog (noreply@blogger.com) at October 28, 2019 12:02 PM

October 24, 2019

Chromium Blog

Automatically lazy-loading offscreen images & iframes for Lite mode users

In Chrome 76, we introduced native lazy-loading for images and iframes via the `loading` attribute - a developer opt-in. In Chrome 77, Chrome Android users with  Lite Mode (Data Saver) enabled will benefit from native lazy-loading of images and iframes automatically.




Lite mode has allowed Chrome to reduce users’ data usage by up to 60 percent, often by compressing the pages users request before downloading them. 



Web pages commonly have images or embedded content that is out-of-view near the bottom of the page, and users typically don’t scroll all the way down to discover them. Today, devices need to use resources loading this content, which is challenging for users on a limited data-plan or with a spotty network connection.



When a user has Lite Mode enabled on Chrome for Android, Chrome will defer the load of below-the-fold images and iframes until the user scrolls near them. This is done without requiring developer action. Automatic lazy-loading helps to reduce network data use and memory use. It may also increase site speed, by prioritizing content visible to the user.



In our experiments, native lazy-loading of images and iframes yields a ~10% reduction in bytes downloaded per page at the 75th percentile and an 8% reduction in overall downloaded bytes for the median user. Automatic lazy-loading also led to a 1-2% improvement in First Contentful Paint at the median, a 2% improvement in First Input Delay at the 95th percentile and a 0.7% improvement in median memory reduction per page. We expect increased benefits as we tune the feature.



Chrome’s native lazy-loading has different distance thresholds after which deferred content will start loading, based on factors such as the effective connection type. This distance is chosen so that content we’ve deferred almost always completes loading by the time it becomes visible. 



Any <iframe> or <img> with the `loading` attribute value of `auto` will also be eligible for Lite Mode’s automatic lazy-loading. This includes <picture> elements and CSS background images.  



It is important to note that automatic lazy-loading of images and iframes is only done if a user has Lite Mode enabled. Lite Mode is most heavily used in areas of the world with poor and expensive connectivity and we believe it is users in these regions that will benefit the most from the feature. Sites wishing to learn what percentage of users have Lite Mode turned on can monitor truthy values from the  SaveData JavaScript API in their analytics.



To enable Lite mode, select Settings > Lite mode and toggle the setting to On. We look forward to this feature helping users keep their page loads just a little bit lighter.




Posted by Addy Osmani, Scott Little and Raj T - lazy Chrome engineers.

by Chromium Blog (noreply@blogger.com) at October 24, 2019 10:00 AM