Posted by Marja Hölttä and Daniel Vogelheim, Resident Loader Coders

Speed has always been one of Chrome's primary missions, ever since it was included as one of the founding principles in 2008. But speed is about more than just traditional Javascript benchmarks. Ideally every part of a user's interaction with a browser is fast, starting with loading web pages. Chrome is introducing two techniques called script streaming and code caching designed to reduce that painful waiting time spent staring at a white screen, especially on mobile devices.

Script streaming optimizes the parsing of JavaScript files. Previous versions of Chrome would download a script in full before beginning to parse it, which is a straightforward approach but doesn't fully utilize the CPU while waiting for the download to complete. Starting in version 41, Chrome parses async and deferred scripts on a separate thread as soon as the download has begun. This means that parsing can complete just milliseconds after the download has finished, and results in pages loading as much as 10% faster. It's particularly effective on large scripts and slow network connections.
Code caching is another new technique that helps speed up page loading, specifically on repeated visits to the same page. Normally, the V8 engine compiles the page’s JavaScript on every visit, turning it into instructions that a processor understands. This compiled code is then discarded once a user navigates away from the page as compiled code is highly dependent on the state and context of the machine at compilation time. Chrome 42 introduces an advanced technique of storing a local copy of the compiled code, so that when the user returns to the page the downloading, parsing, and compiling steps can all be skipped. Across all page loads, this allows Chrome to avoid about 40% of compile time and saves precious battery on mobile devices.

These are two examples of ways Chrome is improving page load time, but page load time is just one way to think about the performance of the browser. Stay tuned for more ways the Chromium project is pushing forward all aspects of performance on the web.


The newest Chrome Beta channel release includes support for ES6 Classes and several new features that allow developers to create more immersive web applications. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux and Chrome OS.

Push Notifications

This release includes two new APIs that together allow sites to push native notifications to their users even after the page is closed—provided the user has granted explicit permission. After the user has granted permission, a developer can use the new Push API to remotely wake up their service worker using Google Cloud Messaging. Once awake, the service worker may run JavaScript for a short period but in this release it is required at minimum to show a user-visible notification. Each notification includes a ‘Site Settings’ button, allowing users to easily disable notifications for a site.

Screen Shot 2015-03-04 at 2.35.05 PM copy.png

Promoting Add to Home Screen

Chrome 32 introduced the ability for Android users to add home screen shortcuts to their favorite websites via a menu item. In this release, users who frequently visit a high-quality web app will see a banner that allows them to add the site to their home screen in one tap.

Sites that wish to take advantage of this new feature must meet eligibility criteria that ensure that users have a good experience when launching sites from the home screen, even when offline. The criteria will evolve over time based on feedback from users and developers, but today they require sites to provide a Web App Manifest, serve all content using HTTPS, and at least partially work offline using a service worker.

ES6 Classes

Developers often find it hard to adapt to JavaScript’s prototype-based inheritance and although many libraries have introduced their own patterns for emulating classes, the language hasn't yet provided a single, uniform way of describing them.

ES6 classes solve this by providing JavaScript a clean, standardized syntax for classes. This new syntax is available in Chrome 42 for JavaScript written in strict mode.
'use strict';

class Polygon {
   constructor(height, width) { = 'Polygon';
       this.height = height;
       this.width = width;

   sayName() {
       log('Hi, I am a ', + '.');

let p = new Polygon(300, 400);

Other updates in this release

  • DevTools now allows developers to visually edit cubic beziers directly from the styles pane, making it easier to understand and modify animations.
  • The Fetch API is now available in the window context, shared workers, and dedicated workers, providing a new promise-based standard for AJAX requests.
  • The startRendering method of an OfflineAudioContext instance now returns a promise that resolves when the audio has finished rendering, making it easier to design web apps that work with the Web Audio API.
  • AudioBufferSourceNode.buffer can no longer be set more than once, protecting developers from the lack of control over when the new source starts.
  • Chrome OS now supports screen.orientation and fires the DeviceOrientationEvent when the device’s orientation changes significantly, allowing orientation-aware websites to operate correctly on Chrome OS devices.
  • This release includes an updated and unprefixed implementation of Encrypted Media Extensions, which allows media sites to discover and interact with digital rights management systems..
  • A new content setting allows users to automatically pause non-primary plugin content to save power. Developers can turn it on to test how it interacts with their content.

As always, visit for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.


It seems like yesterday that Chrome was first introduced on mobile devices to users running Android 4.0 Ice Cream Sandwich (ICS). Since then, twenty-four new Chrome releases and three new Android versions (Jellybean, Kitkat and Lollipop) have shipped. We’ve worked hard to make sure each version was faster, simpler and more secure than the last.

In the last year, we’ve seen the number of Chrome users running ICS drop by thirty percent. Developing new features on older phones has become increasingly challenging, and supporting ICS takes time away from building new experiences on the devices owned by the vast majority of our users. So, with Chrome’s 42nd release, we’ll stop updating Chrome on ICS devices. After Chrome 42, users on ICS devices can continue to use Chrome but won’t get further updates.

We’re excited to sharpen our focus on moving the web forward. If you’re interested in learning more about this change, please see the FAQ's.


Tim Willis, Hacker Philanthropist, Chrome Security Team
Around this time each year we announce the rules, details and maximum cash amounts we’re putting up for our Pwnium competition. For the last few years we put a huge pile of cash on the table (last year it was e million) and gave researchers one day during CanSecWest to present their exploits. We’ve received some great entries over the years, but it’s time for something bigger.

Starting today, Pwnium will change its scope significantly, from a single-day competition held once a year at a security conference to a year round, worldwide opportunity for security researchers.

For those who are interested in what this means for the Pwnium rewards pool, we crunched the numbers and the results are in: it now goes all the way up to $∞ million*.

We’re making this change for a few reasons:

  • Removing barriers to entry: At Pwnium competitions, a security researcher would need to have a bug chain in March, pre-register, have a physical presence at the competition location and hopefully get a good timeslot. Under the new scheme, security researchers can submit their bugs year-round through the Chrome Vulnerability Reward Program (VRP) whenever they find them.
  • Removing the incentive for bug hoarding: If a security researcher was to discover a Pwnium-quality bug chain today, it’s highly likely that they would wait until the contest to report it to get a cash reward. This is a bad scenario for all parties. It’s bad for us because the bug doesn’t get fixed immediately and our users are left at risk. It’s bad for them as they run the real risk of a bug collision. By allowing security researchers to submit bugs all year-round, collisions are significantly less likely and security researchers aren’t duplicating their efforts on the same bugs.
  • Our researchers want this: On top of all of these reasons, we asked our handful of participants if they wanted an option to report all year. They did, so we’re delivering.

Logistically, we’ll be adding Pwnium-style bug chains on Chrome OS to the Chrome VRP. This will increase our top reward to $50,000, which will be on offer all year-round. Check out our FAQ for more information.

Happy hunting!

* Our lawyercats wouldn’t let me say “never-ending” or “infinity million” without adding that “this is an experimental and discretionary rewards program and Google may cancel or modify the program at any time.” Check out the reward eligibility requirements on the Chrome VRP page.

[Cross-posted on the Android Blog]

Many Android apps use a WebView for displaying HTML content. In Android 5.0 Lollipop, Google has the ability to update WebView independently of the Android platform. Beginning today, developers can use a new beta channel to test the latest version of WebView and provide feedback. WebView updates bring numerous bug fixes, new web platform APIs and updates from Chromium. If you’re making use of the WebView in your app, becoming a beta channel tester will give you an early start with new APIs as well as the chance to test your app before the WebView rolls out to your users. The first version offered in the beta channel will be based on Chrome 40 and you can find a full list of changes on the chromium blog entry. To become a beta tester, join the community which will enable you to sign up for the Beta program; you’ll then be able to install the beta version of the WebView via the Play Store. If you find any bugs, please file them on the Chromium issue tracker.

Richard Coles - Software Engineer, Google London

HTTP is the fundamental networking protocol that powers the web. The majority of sites use version 1.1 of HTTP, which was defined in 1999 with RFC2616. A lot has changed on the web since then, and a new version of the protocol named HTTP/2 is well on the road to standardization. We plan to gradually roll out support for HTTP/2 in Chrome 40 in the upcoming weeks.

HTTP/2’s primary changes from HTTP/1.1 focus on improved performance. Some key features such as multiplexing, header compression, prioritization and protocol negotiation evolved from work done in an earlier open, but non-standard protocol named SPDY. Chrome has supported SPDY since Chrome 6, but since most of the benefits are present in HTTP/2, it’s time to say goodbye. We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN.

We’re happy to have contributed to the open standards process that led to HTTP/2, and hope to see wide adoption given the broad industry engagement on standardization and implementation. We also look forward to further advancements in fundamental Internet protocols that lead to a faster and more secure Internet for everyone.

Posted by Chris Bentzel, Multiplexing Manager and Bence Béky, HTTP/2 Enabler

Today’s Chrome Beta channel release includes new Javascript ES6 features and improved workflows for debugging Service Workers and Web Animations. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

ES6 Template Literals

There are many pitfalls of working with strings on the modern web. The Javascript we know today lacks basic string formatting features, doesn’t support multi-line strings, and makes it difficult to protect users from XSS attacks when inserting user-generated content into pages.

Template Literals, introduced in this release, aims to solve these problems. Its basic form adds string formatting into Javascript by providing syntactic sugar for concatenating strings, variables, and the results of functions. Specifically, expressions can be embedded directly into strings when using the backtick operator (`).

var name = "John";
var message = `Hello, ${name}!`;  // Expected result: "Hello John!"

Any code contained within the braces and preceded by the dollar sign will automatically be evaluated and inserted into place.

var message = `1 + 1 = ${1 + 1}!`;  // Expected result: "1 + 1 = 2!"

Besides accepting multi-line strings, Template Literals also introduces the concept of tagged templates which are useful for escaping HTML to prevent XSS attacks and when internationalizing a site.

New features in Chrome Developer Tools

Chrome 36 added Web Animations, unifying several of the animation APIs on the web. This release makes visual debugging easier by allowing developers to slow down playback of their animations on the fly within DevTools.

In Chrome 40 we shipped Service Workers, enabling developers to make their sites load faster and work offline by intercepting network requests to deliver programmatic or cached responses. Until now, developers had to inspect their Service Worker’s cache manually by printing out its contents to the console, making debugging slow. Today’s Beta includes a new section in DevTools for viewing Service Worker caches which can be found by inspecting a Service Worker on chrome://serviceworker-internals.

Other updates in this release

  • ES6 Lexical Declarations cause variables declared with the 'let' keyword to be scoped to their containing block instead of being hoisted to the top of their containing function, giving developers more control over Javascript's tricky scoping rules.
  • The new CSS value image-rendering: pixelated allows scaled images to appear to be composed of very large pixels, trading smooth results for faster image scaling.
  • CSS Media Queries now support any-pointer and any-hover, which function similarly to pointer and hover but can be triggered by any input device, not only the primary one.
  • The Web Audio API now allows developers to temporarily suspend an AudioContext when it’s not in use, improving power consumption. StereoPannerNode is also now supported, enabling left-right panning of an incoming audio stream while maintaining equal power.
  • HTTPS sites that have certificate chains using SHA-1 that are valid past January 1st, 2017 will be treated as “affirmatively insecure” in Chrome UI from this release onwards as part of our plan to gradually sunset SHA-1.
  • Update February 13th: The new CSS values mix-blend-mode and isolation provide control over how an HTML or SVG element blends with the content behind it.

As always, visit for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

`Posted by ${"Erik Arvidsson"}, Software Engineer`