All Feeds | XSL | RSS | Embed | Edit

Real-world JavaScript performance

The V8 JavaScript engine is a cornerstone of fast browsing in Chrome. Over the course of the past year, the V8 team has developed a new method for measuring performance against snapshots of real web pages. Using insights from real-world measurements, the V8 team improved the speed of the average page load in Chrome by 10-20% over the course of the past year.

Historically, JavaScript engines such as V8 used benchmarks like Octane to improve the “peak” performance of JavaScript, or the performance of CPU-intensive script in hot loops. At the beginning of last year, the V8 team started to measure performance with higher fidelity by instrumenting snapshots of popular web pages such as Reddit, Twitter, Facebook, and Wikipedia. This analysis revealed that while peak performance benefits certain types of large web applications, browsing typical websites relies more on “startup” performance, or the speed it takes to start running script. Using insights gleaned from this real-world performance data, the V8 team implemented optimizations which improved mean page load between Chrome 49 and Chrome 56 by 10-20%, depending on CPU architecture.

The web page snapshots also enabled analysis of the differences between various benchmarks and real web workloads. Although no benchmark can be a representative proxy for all sites, the Speedometer benchmark is an approximation of many sites due to its inclusion of real web frameworks including React, Angular, Ember, and jQuery. This similarity can be seen in the startup optimizations above, which also yielded a 25-35% improvement in Chrome’s Speedometer score. Conversely, comparing page snapshots to Octane revealed that Octane was a poor approximation of most websites. Given the plateau of Octane scores across web browsers and the over-optimization of peak performance, we decided to retire the benchmark as a general-purpose measure of real-world JavaScript performance.

V8 performance optimizations improved Chrome's Speedometer score by 25-35% over the past year

Going forward, we plan to ship more JavaScript performance improvements for new patterns of script appearing on the web, including modern libraries, frameworks, and ES2015+ language features. By measuring real-world websites rather than traditional benchmarks, we can better optimize JavaScript patterns that matter most to users and developers. Stay tuned for updates about our new engine architecture, designed for real-world performance.

Posted by Seth Thompson, V8 Track Commentator

Scroll anchoring for web developers

One of the strengths of the web is progressive loading, which means that there is no install step and users can start consuming content almost immediately while the site keeps loading. But progressive loading can also result in annoyances, such as an unexpected page jump when offscreen content loads and pushes down what’s currently on the screen. This can be even worse on mobile devices, since smaller screens mean more content is offscreen and page jumps are more likely.

Since its early days, Chrome has taken a stand against bad or abusive content. For instance, Safe Browsing warns users before they visit malicious websites, and visual indicators on tabs allow our users to quickly track down the source of unexpected noise. Similar to other features designed to protect our users from bad experiences, starting in version 56 Chrome prevents these unexpected page jumps with a new feature called scroll anchoring. This feature works by locking the scroll position on an on-screen element to keep our users in the same spot even as offscreen content continues to load.

Side by side comparison of a web page with scroll anchoring disabled (left) and enabled (right).

Due to the expressiveness of the web, there might be some content for which scroll anchoring is either unwanted or misbehaving. For this reason, this feature ships alongside the ”overflow-anchor” CSS property to override the functionality. To further minimize potential issues, scroll anchoring is disabled on complex interactive layouts via suppression triggers, and on back/forward navigations to allow for scroll restoration.

Today, scroll anchoring is preventing about three page jumps per page-view, but with your help it could be even better. Get involved by participating in the scroll anchoring Web Platform Incubator Community Group, submitting feedback via, and designing your websites or services with a no-reflow mindset.

Posted by Steve Kobes, “The Unbouncer”

Chrome 58 Beta: IndexedDB 2.0, an improvement to iframe navigation, and immersive full screen for PWAs

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

IndexedDB 2.0

The IndexedDB 2.0 standard is now fully supported in Chrome, making it simpler to work with large data sets in the browser. IDB 2.0 features new schema management, bulk action methods, and more standardized handling of failures.

The structure of a site’s database has large performance impacts and can be difficult to change. To simplify updates, object stores and indexes can now be renamed in-place after a refactoring. Sites can also use more natural keys without worrying about a performance penalty thanks to binary keys, which allow compact representations for custom keys.

Data retrieval is easier with the getKey() and openKeyCursor() methods, which also provide better performance when only a database key is needed. The new continuePrimaryKey() cursor method makes it easier to divide large data access across transactions and page loads without worrying about duplicate primary keys. The getAll() and getAllKeys() methods allow bulk recovery of entire datasets without the need for a cursor.

An improvement to iframe navigation

Third-party content, such as advertising, that automatically redirects the page can annoy users and create security issues. Because of this, developers are able to put third-party content inside sandboxed iframes to prevent this behavior. However, in some cases this type of content needs to navigate the top-level page when clicked, like a standard advertisement.

To address this, Chrome 58 now supports the new iframe sandbox keyword allow-top-navigation-by-user-activation. This keyword gives sandboxed iframes the ability to navigate the top-level page when triggered by user interaction, while still blocking auto-redirects.

Immersive full screen for PWAs

When Progressive Web Apps (PWAs) are launched from the Android Home screen, they launch in a standalone app-like mode that hides the omnibox. This helps create an engaging user experience, and frees up screen space for content. However, for even more immersive experiences like games, video players, or other rich content, other mobile UI elements such as the system bars can still be a distraction.

Now PWAs can provide a fully immersive experience by setting display: fullscreen in their web app manifest, which hides non-app UI when the site is launched from the home screen.

         A PWA launched from the home screen (left), launched from the home screen in standalone mode (middle), and launched from the home screen in fullscreen mode (right).

Other features in this release

Deprecations and interoperability improvements

Posted by Victor Costan, IndexedDB Interloper

Faster 3D rendering with WebGL 2.0

The WebGL JavaScript API exposes hardware-accelerated 3D graphics to the web. Chrome 56 brings support for WebGL 2.0, a major upgrade to the API which unlocks a variety of new graphics features and advanced rendering techniques. WebGL 2.0 is currently available for Chrome users with modern graphics hardware on Windows, macOS, and Linux, and is coming soon to Android.

Screen Shot 2017-03-15 at 3.12.13 PM.png
WebGL 2.0 Transform Feedback demo (live link, Github repository)

WebGL 1.0 first launched in Chrome 6 years ago and gave web developers the ability to create immersive plugin-free graphics experiences, from remixing World Cup plays in real-time to visualizing a rock climbing route in a news article. WebGL 2.0 makes it even easier to build 3D web applications, with faster real-time rendering, new types of textures and shaders, and reduced video memory consumption.  Techniques including deferred shading, tone mapping, volumetric effects, and particle effects can now be efficiently implemented. The new APIs also bring WebGL up to feature parity with OpenGL ES 3.0, a graphics platform commonly used in mobile games.

In addition to new rendering capabilities, WebGL 2.0 also introduces a substantially expanded conformance test suite with over 340,000 test cases to help ensure that different web browsers offer compatible graphics platforms. Chrome passes 100% of these test cases across multiple GPU vendors on every desktop platform, ensuring that its WebGL 2.0 implementation is stable and consistent.

To get started using WebGL 2.0, check out the WebGL 2.0 Samples Pack, which contains small self-contained examples of most new API features. You can also see WebGL 2.0 in action in After the Flood1, an interactive demo by PlayCanvas, created in conjunction with Mozilla. Finally, check back here for more news about future graphics features, such as OpenGL ES 3.1 support and explorations into a lower-level web graphics API supporting the new explicit graphics interfaces like Vulkan, Metal, and DirectX 12.

Posted by Zhenyao Mo, Software Engineer

[1] If this demo or other WebGL 2.0 content doesn’t run on your machine, you may need to update your graphics hardware or driver.

Reducing power consumption for background tabs

Efficient power usage is an important aspect of speed, one of Chrome’s key pillars. To prolong battery life, Chrome should minimize power impact from things users can’t see. This includes background tabs,  which consume a third of Chrome's power usage on desktop. Starting in version 57, Chrome will throttle individual background tabs by limiting the timer fire rate for background tabs using excessive power.

Chrome has focused on improving the user experience by throttling tab performance for many years. Like many browsers, Chrome has limited timers in the background to only run once per second. Via the new throttling policy, Chrome 57 will delay timers to limit average CPU load to 1% of a core if an application uses too much CPU in background. Tabs playing audio or maintaining real-time connections like WebSockets or WebRTC won’t be affected.

We've found that this throttling mechanism leads to 25% fewer busy background tabs. In the long-term, the ideal is for background tabs to be fully suspended and instead rely on new APIs for service workers to do work in the background. Chrome will continue to take steps in this direction to prolong users' battery life, while still enabling all the same experiences developers can build today.

Posted by Alexander Timin, Software Engineer and Power Saver

Chrome 57 Beta: CSS Grid Layout, Improved Add to Home screen, Media Session API

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

CSS Grid Layout

Sites are increasingly being accessed on screens of all sizes, from large LCD TVs to tiny watch faces. Historically, supporting all of these screen sizes required complex combinations of markup and CSS, making code hard to maintain. To give developers more granular control over how elements grow and shrink to fit the current screen size, CSS Grid Layout is now available.

CSS Grid supports a two-dimensional grid-based layout system, optimized for responsive user interface design. Elements within the grid can be specified to span multiple columns or rows. Elements positioned in a CSS grid can also be named, making layout code easier to understand.
Screenshot 2017-01-25 20.06.19.png
CSS Grid allows developers to arbitrarily place elements on a grid with full control over element flow, sizing behavior and responsiveness.

Improved Add to Home screen

Update (2017/03/09): Improved Add to Home screen is now planned to launch in Chrome 58.

Since early versions of Chrome for Android, users have been able to add sites to their Home screen for fast and convenient access. This feature adds the icons using Android shortcuts, which means that web apps don’t show up throughout Android in the same way as installed native apps.

In this release, when a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way. For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.

Media Session API

Media consumption is one of the most common uses for the mobile web. In Chrome for Android, developers can customize the lock screen UI and notifications with media content using the new Media Session API. By providing metadata to the browser about the content being played, developers can create rich lock screen messaging that includes information such as title, artist, album name, and artwork. Additionally , the site is now able to respond to user actions taken on the notification itself, such as seeking or skipping.


Other features in this release

Deprecations and interoperability improvements

Posted by Xi Han, Home Screen Heroine

Integrating Progressive Web Apps deeply into Android

In 2015, we added a new feature to Chrome for Android that allows developers to prompt users to add their site to the Home screen for fast and convenient access. That feature uses an Android shortcut, which means that web apps don’t show up throughout Android in the same way as installed native apps. For example, many developers have asked for their web app to show up in the app drawer section of the launcher. These differences can be confusing for users and prevent the experience from feeling as cohesive as it could.

In the next few weeks we’ll be rolling out a new version of this experience in Chrome beta. With this new version, once a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way than before. For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.

This new Add to Home screen feature is one more step in our journey to empower developers to build the best possible experience for their users, and we are committed to ensuring the same mechanisms for installing Progressive Web Apps are available to all browsers on Android.

Posted by Yaron Friedman, Add to Home screen aficionado

Open-sourcing Chrome on iOS!

Historically, the code for Chrome for iOS was kept separate from the rest of the Chromium project due to the additional complexity required for the platform. After years of careful refactoring, all of this code is rejoining Chromium and being moved into the open-source repository.

Due to constraints of the iOS platform, all browsers must be built on top of the WebKit rendering engine. For Chromium, this means supporting both WebKit as well as Blink, Chrome's rendering engine for other platforms. That created some extra complexities which we wanted to avoid placing in the Chromium code base.

Given Chrome's commitment to open-source code, we've spent a lot of time over the past several years making the changes required to upstream the code for Chrome for iOS into Chromium. Today, that upstreaming is complete, and developers can compile the iOS version of Chromium like they can for other versions of Chromium. Development speed is also faster now that all of the tests for Chrome for iOS are available to the entire Chromium community and automatically run any time that code is checked in.

We value the open source community and all of our contributors, and we're glad that Chrome for iOS can finally join in.

Posted by Rohit Rao, Upstream Angler

Performance improvements in Chrome's rendering pipeline

Speed is one of Chrome’s four core principles, enabling web developers to provide users with faster, more engaging web experiences. While many components in the browser contribute to overall speed, the rendering pipeline is primarily responsible for ensuring websites display at 60 frames per second (fps), which feels fast and responsive to users. Over the last few months we’ve rolled out several performance improvements to Chrome’s rendering pipeline, making it even smarter about the work it completes. Chrome now more intelligently skips redundant tasks, chooses optimal rendering algorithms, and better utilizes system hardware, causing websites to load faster, run smoother, and use less power.

In order to display content at 60fps, Chrome has only 16ms to render each frame, including JavaScript execution, style, layout, painting, and pushing the resulting pixels to the user’s screen. Of that 16ms time budget, the less Chrome uses, the more time web developers have to run scripts, load content, and delight their users. Many of our recent improvements to the rendering pipeline focus on reducing the per-frame workload, rather than simply improving Chrome’s raw speed.

For example, when Chrome is preparing to paint pixels to the screen, it must first identify which elements on the page need to be redrawn and which can be copied from the previous frame’s cache. On highly dynamic pages with frequent DOM changes, this performance cost can add up quickly. To simplify this task, Chrome now tracks the draw commands generated for each element and can identify visually non-overlapping subsets. If one of these subsets hasn’t been modified, the entire block can be copied directly from the cache without any additional work. This optimization reduces the time it takes to paint a new frame to the screen by up to 35%.

Chrome also groups the pixels into tiles to enable smaller and faster updates to the screen. Previously, Chrome would redraw any of these tiles that had been modified by a DOM update, but this is only optimal if the majority of a tile’s area needs to be redrawn. If only a few pixels have changed, it’s faster to copy the entire tile from the previous frame and then update the new pixels. Chrome can now intelligently choose the redraw pipeline that will be faster, reducing tile redraw time by up to 40%.

Any update to the screen, such as the input cursor blinking, would previously require the whole tile to be re-rendered (left). When only a few pixels have changed, Chrome can now redraw only the modified region (right).

In addition to intelligently optimizing its workload, Chrome is now better at choosing how it completes that work given the underlying hardware. While video and canvas elements have been GPU accelerated for a long time, Chrome is constantly getting better at utilizing the GPU for more challenging rendering tasks. On Android, Mac, and Windows, Chrome now better utilizes GPU acceleration for complex site content rendering. This improves animation performance, input latency, and scroll smoothness for modern SVG and HTML5 pages.

There are many different dimensions to speed, and we’re committed to continually improving Chrome’s performance and enabling developers to optimize their user experience to hit 60fps. The rendering pipeline is only one piece of the puzzle, and we’ve got a lot more coming. Stay tuned as we continue taking deep dives into performance and steadily make the web faster and more responsive for all Chrome users.

Posted by Chris Harrelson, Painting Professional

Reload, reloaded: faster and leaner page reloads

Reload has long been a staple feature of web browsers and kept its original behavior throughout the years, despite the changing landscape of web platform innovations, connectivity, and content consumption patterns. When reloading a page, browsers will check with the web server if cached resources are still usable, a process known as validation. This typically results in hundreds of network requests per page issued to dozens of domains. On mobile devices, the high latency and transient nature of mobile connections mean that this behavior can produce serious performance issues. In the latest version of Chrome, changes to page reload behavior produce reloads that are 28% faster and result in 60% fewer validation requests.

Users typically reload either because a page is broken or the content seems stale. The existing reload behavior usually solves broken pages, but stale content is inefficiently addressed by a regular reload, especially on mobile. This feature was originally designed in times when broken pages were quite common, so it was reasonable to address both use cases at once. However, this original concern has now become far less relevant as the quality of web pages has increased. To improve the stale content use case, Chrome now has a simplified reload behavior to only validate the main resource and continue with a regular page load. This new behavior maximizes the reuse of cached resources and results in lower latency, power consumption, and data usage.

Despite being a relatively minor change, the new behavior makes reloads up to 28% faster and consume less bandwidth and power. Furthermore, Facebook contacted us with data showing that Chrome was sending validation requests at three times the rate of other browsers. Thanks to the new reload behavior and some related changes, Facebook now reports 28% faster page reloads and 60% less validation requests from Chrome.

We hope this faster reload will come in handy whenever you want to get the latest content on your favorite website or quickly recover from a flaky connection in the subway.

Posted by Takashi Toyoshima, “Reloader Sensei”

Introducing the WebVR API in Chrome for Android

Virtual Reality (VR) is rapidly growing in popularity, and now it's coming to the web. The power of the web is that it can allow VR to work across browsers and hardware, accessible via a single click. This enables VR developers to broadly reach users across multiple types of headsets with a single web app. Here’s how to get started.
Chrome 56 for Android is now available in beta, and web developers can sign up for an Origin Trial which enables the WebVR API and GamePad API extensions. The WebVR API provides access to the input and output capabilities of virtual reality devices such as Daydream View. It also provides access to the user’s position and orientation, so that web apps can render a stereoscopic 3D scene to the headset's display. The Gamepad API extensions provide access to input from motion controllers, such as the Daydream controller, and enables natural interactions in VR.
Origin Trials allow a developer to temporarily enable the feature for all Chrome users visiting their website. The WebVR API is still evolving and will undergo further changes based on developer feedback before being enabled by default for all pages. WebVR will be extended to desktop platforms and Google Cardboard in a future Chrome release, and several performance improvements are coming in Chrome 57.
To learn how to get started and build your first WebVR web app, visit the WebVR developer site for tutorials and samples. Join the conversation by giving feedback on the API or the Chrome implementation and joining the WebVR Slack channel.
Posted by Brandon Jones, Virtual Reality Plumber

Roll-out plan for HTML5 by Default

Four months ago we announced that we’d be moving to HTML5 By Default to offer a safer, more power-efficient experience. As a reminder, this change disables Adobe Flash Player unless there’s a user indication that they want Flash content on specific sites, and eventually all websites will require the user’s permission to run Flash. To ensure a smooth transition, not all users and sites will be affected immediately. HTML5 by Default and the associated user prompts will be introduced gradually as follows.
The feature will be rolled out to users over a few months. HTML5 By Default will be enabled for 1% of users of Chrome 55 Stable in the next few days. The feature is also enabled for 50% of Chrome 56 beta users. With Chrome 56 stable in February, we plan to enable it for all users.
Starting in January users will be prompted to run Flash on a site-by-site basis for sites that they have never visited before. We want to avoid over-prompting users, so over time we’ll tighten this restriction using Site Engagement Index, a heuristic for how much a user interacts with a site based on their browsing activity. In October all sites will require user permission to run Flash.
More details, including specific Site Engagement Index thresholds, are available on the Flash Roadmap Page. Developers can find recommendations on how to test their Flash sites there as well. As sites transition from Flash to HTML5, this change will no longer affect them and the entire web will become faster, more secure and power-efficient.
Posted by Eric Deily, wrangler of the Default

Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

“Not Secure” warning for HTTP password and credit card pages

To help users browse safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Starting in version 56, Chrome will mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure. The feature will roll out gradually over the next few weeks.

To avoid being labeled insecure, sites should secure their traffic with HTTPS and follow general security guidelines.

Chrome ‘Not Secure’ warning appearing in the URL bar for a site with an HTTP connection  

Web Bluetooth

Sites can now interact with Bluetooth Low Energy (BLE) devices using the Web Bluetooth API on Android, Chrome OS, and Mac. The Web Bluetooth API uses the GATT protocol, which enables web developers to connect to bluetooth devices such as printers and LED displays with just a few lines of JavaScript. Web Bluetooth can also be combined with Physical Web beacons to discover and control nearby devices. To get started, check out these samples and demos on GitHub.  

An Android device connecting to a BLE-enabled heart rate monitor via the web (source)

CSS position: sticky

Chrome now supports CSS position: sticky, a new way to position elements. A position: sticky element is relatively-positioned, but becomes position: fixed after the user reaches a certain scroll position.

Previously, building content headers that scrolled normally until sticking to the top of the viewport required listening to scroll events and switching an element’s position from relative to fixed at a specified threshold. This solution was difficult to synchronize, resulting in small visual jumps. Now, users can achieve the desired effect by simply positioning their elements as sticky.

Other features in this release

Deprecations and interoperability improvements

Posted by Vincent Scheib, Web Bluetooth Orthodontist

Chrome Dev Summit 2016: The Mobile Web Moves Forward

Last week at the 4th annual Chrome Dev Summit, we were excited to share a glimpse of what’s possible with over 1,000 developers in person, and thousands more on the livestream. Each year this is a time to hear what developers have been building, share our vision for the future of the web platform, and celebrate what we love about the web...

Reach of the web
As we've talked about before, one of the superpowers of the web is its incredible reach. There are now more than two billion active Chrome browsers worldwide, with many more web users across other browsers. The majority of these users are now on mobile devices, bringing new opportunities for us to explore as an industry.

Mobile browsers also lead the way for the internet’s newest users. Exclusively accessing the internet from mobile devices, users in emerging markets struggle with limited computing power, unreliable networks, and expensive data. For these users, native apps can be a poor match due to their large data and storage requirements. And, it’s these constraints that have resulted in the developing markets leading the charge when it comes to innovating on the web.


Instead, the web can fill these needs for all users through an experience we've been calling Progressive Web Apps (PWAs). These web apps provide the performance users have come to expect from their device, while also offering critical capabilities such as offlining, add-to-homescreen, and push notifications. We've been encouraged by the strong adoption of these capabilities, with push notifications recently exceeding 18 billion notifications per day across 50,000 domains.

Last year when we spoke about PWAs, things were just getting started. Now we're seeing the movement in full swing, with many large sites across the globe launching great new apps and feeling the success that PWAs can bring.

DAY 1 - THAO LOGOS.png, built a PWA and saw a 76% increase in conversion rates across browsers. The investment in the mobile web increased monthly active user rates on iOS by 14 percent. On Android devices where re-engagement capabilities like push notifications and Add to Homescreen were enabled, active user rates increased by 30 percent.

Another great example is The Weather Channel. Since launching a PWA they achieved an 80% reduction in load time and within three months, saw almost 1 million users opt in to receive web push notifications.

During the Summit, we also heard from Lyft, who shared their experience of building a PWA in less than a month, and using less than a quarter of the engineering support needed to build their native app. Learn more about our how partners are using PWA technologies to enhance their mobile web experience.

What can you do?
We also have a variety of tools, libraries, and APIs available to help you bring the benefits of PWAs to your site. For example, Chrome's DevTools provides assistance along every step of the development flow. DevTools has a ton of new features to help you build great mobile apps, such as network simulation, CPU throttling, and a PWA audit tool powered by Lighthouse.

For developers just beginning their web app or looking to rework an existing one, the Polymer App Toolbox provides a set of components and tools for easily building a Progressive Web App using web components. And Polymer 2.0 is right around the corner, making it easy to take advantage of the new Web Components v1 APIs shipping cross-browser and build mobile web apps with minimal overhead.

Finally, checkout can be a complicated process to complete and in the retail sector alone there are 66% fewer conversions on mobile than on desktop. With PaymentRequest, you can now bring a seamless checkout experience to your website with support for both credit cards and Android Pay, increasing odds for conversion.

Catch up
Finally, if you didn’t catch our live stream in real time, you can always check back on our YouTube channel for all the recordings or see the highlights from the event in 57 seconds.

Thanks for coming, thanks for watching, and most of all, thank you for developing for the web!

Posted by Darin Fisher, VP Engineering, Chrome

Here’s to more HTTPS on the web!

Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we’ve worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future. It’s happening now, with secure browsing becoming standard for users of Chrome.

Today, we’re adding a new section to the HTTPS Report Card in our Transparency Report that includes data on how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory.
Percentage pages loaded over HTTPS in Chrome

As the remainder of the web transitions to HTTPS, we’ll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP.

As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we’ve posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.

We’ve seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented “we were able to migrate to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS.” CNET, a large tech news site, had a similar experience. “We successfully completed our move of to HTTPS last month,” said John Sherwood, Vice President of Engineering & Technology at CNET. “Since then, there has been no change in our Google rankings or Google organic search traffic.”

Webmasters that include ads on their sites also carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, “saw no material impact to AdX revenue with the transition to SSL.”

As migrating to HTTPS becomes even easier, we’ll continue working towards a web that’s secure by
default. Don’t hesitate to start planning your HTTPS migration today!

Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team

Making Chrome on Windows faster with PGO

Chrome is always looking for ways to speed up the web. Starting in Chrome 53, Chrome has started using Microsoft’s Profile Guided Optimization (PGO) technology to make Chrome up to 15% faster on Windows.

New tab page load time
14.8% faster
Page load (time to first paint)
5.9% faster
Startup time
16.8% faster
PGO impact on load and startup time

Chrome is a huge software project with more than a million functions in its source code. Not all functions are equal - some are called frequently, while others are rarely used.  PGO uses data from runtime execution that track which functions are most common to guide optimization.
To gather this data, the nightly build process now produces a special version of Chrome that tracks how often functions are used. PGO then optimizes those high-use functions for speed, in some cases increasing the binary size of those functions. To balance out that increase, PGO also optimizes less-used functions with smaller, though slightly slower code. These trade-offs result in higher overall performance, and a smaller overall code footprint.
PGO also optimizes the memory location of the code, moving rarely-used functions away from frequently-used ones in memory.  This results in more optimal use of the CPU instruction cache by avoiding caching of less-used code, increasing overall performance. There are many other tricks that PGO uses to make Chrome faster, and they add up to great results.
64-bit Chrome on Windows is using PGO as of version 53, and 32-bit Chrome is using it as of version 54.  Try out the latest version of Chrome to see the difference with PGO.
Posted by Sébastien Marchand, who is Pretty Good at Optimizing.

Chrome 55 Beta: Input handling improvements and async/await functions

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Input handling improvements

As usage of the mobile web grows, it is increasingly important for sites to react well to touch input. Historically, this meant handling MouseEvent and TouchEvent separately, which can be difficult to maintain. Chrome now enables unified input handling by dispatching PointerEvents. PointerEvents lead to more responsive pages, as they don’t block scrolling by default. To achieve the same performance with TouchEvent, pages can use passive event listeners.

Chrome also now supports two new ways to respond to input. The touch-action CSS property enables sites to react to gestures such as panning. For mouse buttons, the new auxclick input event type allows sites to manage the click behavior of non-primary buttons.   

Async and await functions

Asynchronous JavaScript can be difficult to reason about. Promises help avoid the nesting problem of callbacks, but Promise-based code can still be difficult to read when a site has large chains of asynchronous dependencies. Chrome now supports the async and await JavaScript keywords, allowing developers to write Promise-based JavaScript that can be as structured and readable as synchronous code.

Fetching a URL and logging the response using Promises:

function logFetch(url) {
 return fetch(url)
   .then(response => response.text())
   .then(text => {
   }).catch(err => {
     console.error('fetch failed', err);

The same code using async and await:

async function logFetch(url) {
 try {
   const response = await fetch(url);
   console.log(await response.text());
 catch (err) {
   console.log('fetch failed', err);

CSS automatic hyphenation

Formatting text to fill available space can be a challenge across devices and screen sizes. Chrome now supports CSS automatic hyphenation, one of Chrome’s most frequently requested layout features, on Android and Mac. CSS hyphenation allows the browser to hyphenate words when line-wrapping, improving the visual consistency of text blocks. Hyphenation support will be extended to other platforms in future releases.

A paragraph rendered with and without automatic hyphenation

Other features in this release

  • The once event listener option enables callbacks to be invoked only once before removing the event listener.
  • Sites can now mark web storage as persistent, preventing Chrome from automatically clearing storage for that site.
  • Cross-origin iframes now require a user gesture to start audio playback using the Web Audio API on Android, matching the behavior of the <audio> and <video> elements.
  • The TLS stack now implements GREASE, a mechanism to help prevent problems with buggy TLS servers.
  • Developers can create a MediaStreamTrackEvent in an alternative way with its new JavaScript constructor.
  • RSA-PSS signature algorithms have been added to TLS to prepare for TLS 1.3.
  • To improve load times and prevent failed navigations, cross-origin and parser-blocking scripts injected using document.write() will no longer load over 2G connections.
  • AudioNode constructors of the form new AudioNode(context, options) are now available, making it simpler to manage audio from scripts.
  • When the media player is too narrow to show every button, an overflow menu will appear to provide the hidden functionality to users.
  • Chrome media controls will now display a download button when the playback is associated with a file that can be downloaded.
  • The Web Share API is available for experimentation as an origin trial.

Deprecations and interoperability improvements

  • BaseAudioContext will replace AudioContext in the Web Audio API to conform to spec.
  • CSS Clipping Path properties no longer require the webkit prefix.
  • The MediaStream constructor is now available without prefix alongside the existing webkitMediaStream.
  • Non-script MIME types will no longer trigger script execution.
  • <textarea maxlength=""> and <textarea minlength=""> have been updated to count each line break as one character, instead of two.
  • The webkit prefix has been removed from the imageSmoothingEnabled property of CanvasRenderingContext2D.

Posted by Dan Ehrenberg, Asynchronous Adventurer

Canary channel for Chrome on Android

Chrome supports multiple release channels with varying degrees of stability and support. The Canary channel ships the most bleeding edge version of Chrome possible. It is primarily intended to be used by developers and early adopters to test recent Chromium changes, but anyone can install it and give it a try. Previously the Canary channel was only available on Windows and Mac, and it is now available for Android as well.

Just like the Canary channel for other platforms, new versions are built from the most recent code available and often contain a variety of new features, enhancements, and bug fixes. These builds are shipped automatically with no manual testing, which means that the build can be unstable and may even stop working entirely for days at a time. However, the goal is for Canary to remain usable at all times, and the Chrome team prioritizes fixing major issues as quickly as possible.

Initially, builds will ship every weekday. In the future new builds may also be available on weekends. The frequency of builds means that keeping the app updated will consume a lot of data, typically more than 100MB per week. This is especially important for phones set to update native apps over cellular data.

We hope the Canary channel will be useful when developing and testing changes for Chrome on Android. If you encounter any bugs, please help us by reporting them.

Posted by Alex Mineer, APK Administrator & Bug Basher

Chrome 54 Beta: Custom Elements V1, BroadcastChannel, and media platform improvements

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Custom Elements V1
Complex user interfaces often require a large amount of HTML. Most languages allow developers to create their own components built on top of language primitives to mitigate this kind of verbosity. Custom elements allow developers to create their own custom HTML tags, and define the new element’s API and behavior in JavaScript. This enables a browser-native way to build reusable, interoperable components.

Chrome 54 provides support for the latest custom elements V1 spec, which is broadly agreed-upon by major browser vendors. Chrome will also continue to support the V0 API until enough developers have moved to V1.

It is not uncommon for desktop users to have multiple windows or tabs open simultaneously. Some sites utilize this behavior, such as web editors that open documents in their own tabs. Historically, communicating between those tabs has been difficult. BroadcastChannel is a new one-to-many messaging API between windows, tabs, iframes, web workers, and service workers. It allows scripts to establish named channels to send messages between browsing contexts of the same origin.

Media platform improvements on Chrome for Android
Media is an increasingly large and important part of the browsing experience on mobile devices that requires fluidly utilizing the entire screen. Developers can now use Element.requestFullScreen() to trigger full screen mode after a screen orientation change in addition to after a user gesture. This allows experiences like rotate-to-fullscreen for media players.  

In addition to fullscreen improvements, Chrome on Android now persists the media notification of a backgrounded HTMLVideoElement, allowing a user to continue playing videos while they aren’t visible. Developers can detect background video playback by using the Page Visibility API.

Playing background videos in Chrome 54.

Other features in this release

Deprecations and interoperability improvements
  • To match behavior in other browsers, embedded YouTube Flash players will be rewritten by Chrome to use the HTML5 embed style, improving performance and security on Chrome Desktop.
  • CacheQueryOptions now conforms to spec across all CacheStorage methods.
  • initTouchEvent has been removed in favor of the new TouchEvent() constructor.
  • SVGZoomEvent has been removed as it is no longer part of the SVG 2.0 spec.
  • SVGSVGElement.currentView, SVGSVGElement.useCurrentView, SVGViewSpec interface, and SVGSVGElement.viewport have been removed as they are no longer part of the SVG 2.0 spec.
  • SVGTests.requiredFeatures attribute has been deprecated since it no longer provides useful functionality in the SVG 2.0 spec.
  • SVGElement now supports the dataset property.
  • The KeyEvent.keyIdentifier field has been removed in favor of the KeyboardEvent.key field.
  • window.external.IsSearchProviderInstalled() and AddSearchProvider() are now no-ops, since they are unsupported in most other browsers.

Posted by Marijn Kruisselbrink, Broadcast Buccaneer

Moving Towards a More Secure Web

To help users browse the web safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Beginning in January 2017 (Chrome 56), we’ll mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure. 
Chrome currently indicates HTTP connections with a neutral indicator. This doesn’t reflect the true lack of security for HTTP connections. When you load a website over HTTP, someone else on the network can look at or modify the site before it gets to you. 

A substantial portion of web traffic has transitioned to HTTPS so far, and HTTPS usage is consistently increasing. We recently hit a milestone with more than half of Chrome desktop page loads now served over HTTPS. In addition, since the time we released our HTTPS report in February, 12 more of the top 100 websites have changed their serving default from HTTP to HTTPS.

Studies show that users do not perceive the lack of a “secure” icon as a warning, but also that users become blind to warnings that occur too frequently. Our plan to label HTTP sites more clearly and accurately as non-secure will take place in gradual steps, based on increasingly stringent criteria. Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as "not secure," given their particularly sensitive nature.

In following releases, we will continue to extend HTTP warnings, for example, by labelling HTTP pages as “not secure” in Incognito mode, where users may have higher expectations of privacy. Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.
We will publish updates to this plan as we approach future releases, but don’t wait to get started moving to HTTPS. HTTPS is easier and cheaper than ever before, and enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our set-up guides to get started.

From Chrome Apps to the Web

We have always believed in making the open, interoperable web as strong as possible. For a while there were certain experiences the web couldn’t provide, such as working offline, sending notifications, and connecting to hardware. We launched Chrome apps three years ago to bridge this gap.

Since then, we’ve worked with the web standards community to enable an increasing number of these use cases on the web. Developers can use powerful new APIs such as service worker and web push to build robust Progressive Web Apps that work across multiple browsers. More capabilities will continue to become available on the web.

As we continue our efforts to simplify Chrome, we believe it’s time to begin the evolution away from the Chrome apps platform. There are two types of Chrome apps: packaged apps and hosted apps. Today, approximately 1% of users on Windows, Mac and Linux actively use Chrome packaged apps, and most hosted apps are already implemented as regular web apps. We will be removing support for packaged and hosted apps from Chrome on Windows, Mac, and Linux over the next two years.

All types of Chrome apps will remain supported and maintained on Chrome OS for the foreseeable future. Additional enhancements to the Chrome apps platform will apply only to Chrome OS devices, including kiosks. Developers can continue to build Chrome apps (or Android apps) for Chrome OS.

Starting in late 2016, newly-published Chrome apps will only be available to users on Chrome OS. Existing Chrome apps will remain accessible on all platforms, and developers can continue to update them.

In the second half of 2017, the Chrome Web Store will no longer show Chrome apps on Windows, Mac, and Linux, but will continue to surface extensions and themes. In early 2018, users on these platforms will no longer be able to load Chrome apps.

On Windows, Mac, and Linux, we encourage developers to migrate their Chrome apps to the web. Developers who can’t fully move their apps to the web can help us prioritize new APIs to fill the gaps left by Chrome apps. In the short term, they can also consider using a Chrome extension or platforms such as Electron or NW.js.

As the capabilities of the web continue to grow, we're excited to see what developers build next. Alongside other browser vendors, we remain committed to investment in the web and enabling users and developers to benefit from its openness and reach.

Posted by Rahul Roy-Chowdhury, VP Product Management

Chrome 53 Beta: Shadow DOM, PaymentRequest, and Android autoplay

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Shadow DOM V1

HTML, CSS, and JavaScript are powerful development languages, but they can be difficult to maintain in large code bases. Sites that embed third-party content also need to ensure that included styles do not affect other parts of their app. Chrome 53 supports Shadow DOM V1, which allows an element to encapsulate its style and child DOM away from the main document. This improves the maintainability of large or composed sites. Shadow DOM V1 has some significant changes from the V0 version, and is broadly agreed-upon by major browser vendors. Chrome will support both versions of the API until enough developers have moved to V1. The behavior of a shadow root is determined by which API call it was created with.

PaymentRequest API

Completing payments on the web can be a cumbersome process for users, leading to lower conversions on sites. While autofill has made it easier to enter information, efficient data entry on mobile is still a challenge. PaymentRequest allows for fast, seamless, and secure payments on the web using a credit card or Android Pay. It also lets users provide a billing address, shipping details, and payer information without typing. PaymentRequest is available on Chrome for Android, with support for more platforms coming soon.

Chrome for Android autoplays muted video

Video is a great way for sites to reach their users, but it can be jarring when it plays unexpectedly. This is especially true on mobile, where the user may be in an environment where audio is unwanted. Chrome on Android now allows muted videos to begin playing without user interaction. If the video was marked as muted and has the autoplay attribute, Chrome will start playing the video when it becomes visible to the user. Developers can also use script to play muted videos without user interaction. Muted videos that begin playing sound before a user action will automatically be paused.

Other features in this release

Deprecations and interoperability improvements

Posted by Hayato Ito, Shadow DOM Chaffeur

Universal rendering with SwiftShader, now open source

SwiftShader is a software library for high-performance graphics rendering on the CPU. Google already uses this library in multiple products, including Chrome, Android development tools, and cloud services. Starting today, SwiftShader is fully open source, expanding its pool of potential applications.

Since 2009, Chrome has used SwiftShader to enable 3D rendering on systems that can’t fully support hardware-accelerated rendering. While 3D content like WebGL is written for a GPU, some users’ devices don’t have graphics hardware capable of executing this content. Others may have drivers with serious bugs which can make 3D rendering unreliable, or even impossible. Chrome uses SwiftShader on these systems in order to ensure 3D web content is available to all users.

Chrome running without SwiftShader on a machine with an inadequate GPU (left) cannot run the WebGL Globe experiment. The same machine with SwiftShader enabled (right) is able to fully render the content.

SwiftShader implements the same OpenGL ES graphics API used by Chrome and Android. Making SwiftShader open source will enable other browser vendors to support 3D content universally and move the web platform forward as a whole. In particular, unconditional WebGL support allows web developers to create more engaging content, such as casual games, educational apps, collaborative content creation software, product showcases, virtual tours, and more. SwiftShader also has applications in the cloud, enabling rendering on GPU-less systems.

To provide users with the best performance, SwiftShader uses several techniques to efficiently perform graphics calculations on the CPU. Dynamic code generation enables tailoring the code towards the tasks at hand at run-time, as opposed to the more common compile-time optimization. This complex approach is simplified through the use of Reactor, a custom C++ embedded language with an intuitive imperative syntax. SwiftShader also uses vector operations in SIMT fashion, together with multi-threading technology, to increase parallelism across the CPU’s available cores and vector units. This enables real-time rendering for uses such as app streaming on Android.

Developers can access the SwiftShader source code from its git repository. Sign up for the mailing list to stay up to date on the latest developments and collaborate with other SwiftShader developers from the open-source community.
Posted by Nicolas Capens, Software Engineer and Pixel Pirate

Chrome 52 Beta: CSS containment, simpler performance measurement, streamable responses from service workers, and more options for web push

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.
CSS Containment
Rich, interactive experiences are a cornerstone of the web, but can sometimes take a long time to render due to their complexity. Currently, Chrome improves rendering performance by using heuristics to determine which parts of a page have changed. Only sections that have changed are updated instead of rendering the entire page 60 times per second. However, because elements can display outside the bounds of their parents, it is possible that changes to one element could affect elements anywhere else in the document. This dramatically increases the number of elements that Chrome must consider while rendering.

New in this release, the CSS contain property allows developers to prevent an element’s children from displaying outside of its bounds. When an element updates, this guarantee allows Chrome to ignore any element outside the parent node during rendering, leading to faster rendering times.
Performance Observer
Collecting accurate real-user measurement (RUM) data is critical to detecting performance problems and regressions that may hurt the user experience of a site. Chrome's DevTools allow local site testing, but measuring how a site performs for real users with varied devices can be challenging. The latest version of Chrome supports the PerformanceObserver API, which enables a simple and performant way to collect RUM data at runtime. Instead of polling for updates, sites can declare which metrics they’re interested in. The browser notifies the site when new data points for those metrics become available.
Service Worker Responses Powered by ReadableStreams
Streaming HTTP responses allow browsers to progressively render earlier portions of a large HTML document before the entire response is available. The latest version of Chrome improves service workers by adding streaming support. Sites can use the Streams API to construct streamable Response objects by passing a ReadableStream to the Response constructor.
Offline Wikipedia client demonstrates the speed benefits of readable streams.
Web Push Protocol and VAPID Support
Push notifications have unlocked a new level of re-engagement for web apps, but until now developers have had to use proprietary push message delivery services and different APIs for different browsers. Chrome now supports VAPID, an open standard to authenticate a site’s server with a push service. When using VAPID, sites are given a Firebase Cloud Messaging endpoint, which supports the cross-browser web push protocol.
Other features in this release
Posted by Shubhie Panicker, Performance Powerhouse

The Mobile Web Is Open for Business

Posted by Rahul Roy-chowdhury, VP Product Management, Chrome

One of the virtues of the web is its immense reach, providing access to information for all internet users regardless of device or platform. With the explosion of mobile devices, the web has had to evolve to deliver great experiences on the small screen. This journey began a few years ago, and I am excited to be able to say that the mobile web is open for business. Hear the recording from Google I/O where I discussed the state of the union and how to take advantage of new experiences like AMP and Progressive Web Apps (PWAs) to deliver a best-in-class mobile experience.

If you don’t have time to watch, here’s a quick recap of the four aspects to focus on while building a great mobile web experience:

Expressiveness has always been a strength of the web, but sometimes that expressiveness can come at the cost of loading time or smooth scrolling. For example, event listeners allow developers to create custom scrolling effects for their website, but they can introduce jank when Chrome needs to wait for any touch handler to finish before scrolling a page. With the new passive event listener API, we've given control back to the developer, who can indicate whether they plan to handle the scroll or if Chrome can begin scrolling immediately.

Speed also goes beyond user experience gains. Studies have shown that 40% of users will leave a retail site if it takes longer than 3 seconds to load. To get a blazing fast web page in front of users immediately, we've introduced Accelerated Mobile Pages (AMP). With AMP, we have seen pages load 4x faster and use up to 10x less data. AMP is already seeing great adoption by developers, with more than 640,000 domains serving AMP pages.

Progressive Web Apps (PWAs) let developers take advantage of new technologies to provide users with an engaging experience from the very first moment. Thanks to a new API called service worker, all the important parts of a web app can be cached so that it loads instantly the next time a user opens it. This caching also allows developers to continue to provide a fast and meaningful experience even when the user is offline or on an unreliable network. PWAs provide elements of polish too: an icon users can add to their home screen, a splash screen when they open it, and a full-screen experience with no address bar.

image 9.gif

JalanTikus Progressive Web App

Logging in is a ubiquitous pattern on the web, but 92% of users abandon a task if they've forgotten their password. To alleviate this pain, Chrome's password manager enables more than 8-billion sign-ins per month, and we're expanding support with the Credential Management API. Using this API allows web apps to more closely integrate with the password manager and streamline the sign-in process.

Even once logged in, checkout can be a complicated process to complete. That's why we're also investing in capabilities such as the Web Payment API and enhanced autofill, assisting users by accurately filling in forms for them. We've found that forms are completed 25% more when autofill is available, increasing odds for conversion.

Once the first interaction with a user is complete, re-engaging on the web can be tricky. Push notifications address this challenge on native apps, and now the push API is available on the web as well. This allows developers to reconnect with their users even if the browser isn't running. Over 10 billion push notifications are sent every day in Chrome, and it’s growing quickly. Jumia found that users who enabled push notifications opened those notifications 38% of the time and recovered carts 9x more often than other users.

Jumia Mobile Web Push Notifications

Success Stories
As developers begin embracing these new technologies, we're seeing success stories from around the world. AliExpress, one of the world's largest e-commerce sites, built a PWA and saw conversion rates for new users increase by 104%. They've also found that users love the experience, spending 74% more time on their site per session.

Another great example is BaBe, an Indonesian news aggregator service that was app-only until they developed a PWA with feature parity to their native app. Since launching they have found it to perform even faster than their native app, and have seen comparable time spent per session: 3 minutes on average on both their mobile website and their native app.

Even developers who have only begun implementing certain PWA technologies have seen success. United eXtra, a leading retailer in Saudi Arabia, implemented push notifications and saw users who opted-in returned 4x more often. These returning users also spent 100% more than users returning from other channels.

These are just a handful of businesses that have begun reaping the benefits of investing in Progressive Web Apps. Learn more about our how partners are using PWA technologies to enhance their mobile web experience.

Screen Shot 2016-05-17 at 6.06.16 PM.png

Subscribe to our YouTube channel to stay up to date with all the mobile web sessions from Google I/O, which we will continue to upload as they’re ready. Thanks for coming, thanks for watching, and most of all, thank you for developing for the web!