A good frame rate is important to maintain a fast browsing experience. A few months ago, Chrome added a scheduler, a new under-the-hood feature that places tasks in the idle time between rendering frames to help hit 60 frames per second. Chrome’s frame rate can be reduced by Javascript timers executing at the wrong time, making them a natural next candidate to optimize with the scheduler. The most recent version of Chrome beta reschedules Javascript timers to create a smoother experience when the user is interacting with a page.

Javascript timers enable web developers to write code that checks in on a page periodically with APIs like setTimeout. Advanced developers can use setTimeout to schedule their code at opportune times, but they often don't have enough information to schedule it optimally. A timer’s function is placed into the main execution queue, meaning that if the function is run at the wrong time, it could block time-critical work that shares the queue, like input or rendering. Chrome has signals that important work is incoming, but before M45 they were ignored for timers.

When the user taps the page, they often interact with it again immediately or Chrome needs to re-render part of the screen. The scheduler now delays impending expensive timers after a tap in anticipation of these tasks, allowing many web pages to be scheduled more efficiently. In practice, this can result in up to a 50% input latency improvement on websites that use timers heavily.

The latest version of Chrome scrolling a timer heavy site with no optimizations (left) and delayed timer execution (right).

Scheduling timers intelligently is just one use of the scheduler’s infrastructure. To keep improving, Chrome will continue integrating the scheduler with more rendering engine tasks. Using cycles wisely is one way to keep the web fast for everyone.

Posted by Alex Clarke, Software Engineer and Timer Tamer

Unwanted and deceptively installed extensions are a leading cause of user complaints, and over the last few years we’ve taken several steps to address the problem. Today we’re taking another step in our ongoing effort to protect Chrome users: disabling inline installation for extensions linked to deceptive sites and ads.

Inline installation was introduced in 2011 as a way for users to seamlessly install extensions from developers’ websites. Unfortunately, this mechanism has been abused by deceptive sites and ads that trick users into installing unwanted extensions.  

This ad appears to be a software update but actually links to an inline installation site for a Chrome extension.

To help address this problem, on September 3 we’ll begin disabling inline installation for extensions that employ these deceptive tactics. For these extensions, inline installation attempts will be redirected to the extension’s product details page in the Chrome Web Store, allowing the user to make an informed decision about whether to install.  

Although less than 0.2% of all extensions will be affected by this change, it’s an important step to maintain a healthy extension ecosystem for users and the vast majority of extension developers who don’t use deceptive tactics. If you have any questions regarding this change, please reach out to us at

Posted by Andrew Kim and Ben Ackerman, Chrome Policy and Anti-Abuse Team

The newest Chrome Beta channel release includes new JavaScript language features, an improved audio experience on Android, and a large number of minor API improvements and deprecations. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

New ES2015 features

Over the past year Chrome has shipped a number of new JavaScript features defined in the ES2015 specification (formerly known as ES6), a major update to JavaScript that allows developers to write application logic that is easier to read, more powerful, and more memory efficient than ever before.

Service worker improvements

Chrome 40 introduced support for service workers, enabling developers to build high performance sites that work offline. This release includes a number of improvements:

Finally, in a breaking change, messages sent via Client.postMessage() now fire an event on navigator.serviceWorker instead of the window object.

Media controls in Android notifications

Playback controls for currently-playing audio are shown in the notification tray and on the lock screen

On Android, native apps can show media controls in a system notification when playing audio, making it easy for users to control audio while multitasking. Chrome 45 brings this capability to the web by showing a notification with media controls when audio is playing in web content. The controls will automatically show up when <audio> or <video> tags play audio longer than 5 seconds.

Other updates in this release

Update: The User Timing and Resource Timing APIs are unfortunately not exposed to service workers in this release, but should be available in Chrome 46. As always, visit for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

Posted by Andreas Rossberg, Software Engineer and ECMAScript Evangelizer

Today’s connected world is full of opportunities for people to digitally interact with their surroundings on the fly. For example, smart parking meters let users pay through the cloud. But for developers, it’s often difficult to build contextual experiences that people can easily access. Even with the prevalence of smartphones, users are reluctant to install an app or even type a URL while on the go.

The Physical Web is an open source approach to help you build contextual interactions that people can discover and use with less friction. A few months ago, Chrome for iOS added a Today widget to let users open a new tab or do a voice search right from the Notification Center.  The new Chrome for iOS  integrates the Physical Web into the Chrome Today widget, enabling users to access an on-demand list of web content that is relevant to their surroundings.

It’s easy to make your content discoverable via the Physical Web using Eddystone, an open Bluetooth Low Energy beacon format announced last week. Eddystone supports multiple frame types for different use cases. The Physical Web displays content that is broadcasted using Eddystone-URL, the beacon frame type designed to convey compressed URLs. You can add your content to the Physical Web by simply configuring a beacon that supports Eddystone-URL to transmit your URL of choice.

When users who have enabled the Physical Web open the Today view, the Chrome widget scans for broadcasted URLs and displays these results, using estimated proximity of the beacons to rank the content. You can learn more about the types of user experiences that the Physical Web enables by visiting our cookbook and joining the open source community on GitHub.

The new Chrome for iOS is an early exploration in enabling users to access the Physical Web in their day-to-day mobile experiences. As the ecosystem grows,  we’ll continue to explore new ways to bring the Physical Web to users’ fingertips. We’re looking forward to seeing the new contextual experiences you’ll build.

Posted by Jake Leichtling, Physical Web Explorer

The JavaScript ecosystem is evolving in several promising ways. There have been mainstream standards advancements like the recent approval of ECMAScript 2015, as well as early-stage experiments like Strong Mode, to name a few. Balancing the needs of these new directions demands a flexible just-in-time compiler, and we've been hard at work on a brand new compiler for V8, codenamed "TurboFan." Since Chrome 41, TurboFan has been enabled for certain types of code, speeding up traditional content as well as improving performance for new language features.

TurboFan was built from the ground up with many unique capabilities in mind. It optimizes more code than the previous optimizing compiler, supports flexible and dynamic optimization modes, and enables easier contributions and maintenance. Thanks to these features and more, we've turned on TurboFan for some types of code that were challenging for our previous compiler to optimize, such as asm.js, class literals, with scopes, computed property names and for-of loops. TurboFan already shows promising performance results, including a 29% increase on the zlib score of the Octane benchmark.

Over the coming months, we expect to enable TurboFan for more and more types of JavaScript, with the eventual goal of entirely replacing our existing CrankShaft compiler. As it rolls out, developers' code will automatically get these free speedups with no changes needed. Stay tuned for future progress.

Posted by Ben L. Titzer, Software Engineer and TurboFan Mechanic

On Chrome OS, users should be able to work with files in the cloud as easily as they work with local files.
Today, users often have their files spread all over the cloud -- with documents in one place, their photos in another, and videos somewhere else. Working across all of those systems can be a challenge, which is where the File System Provider API in Chrome OS can help. With the File System Provider API, users who install your Chrome App can have your Cloud service seamlessly integrated into the Chrome OS Files app. Working with multiple storage backends becomes as easy as dragging and dropping files locally.

As usual, users can install your Chrome app or extension from the Chrome Web Store. Or, they can add new services directly from the Files app. The new file system will then appear directly in the left navigation column. Users can browse this file system anywhere the Files app is shown, including Save as and Open dialogs.

Screenshot 2015-04-29 at 12.36.48 PM.png

Your extension just needs to call chrome.fileSystemProvider.mount and respond to the listed events. Developers have already created some great apps, including the official client, an SMB client, and even a way to browse TED talks locally. Check out the documentation or join the mailing list to stay informed about announcements and API changes.

Posted by Tomasz Mikolajewski, Filesystem Fiend

The newest Chrome Beta channel release includes new ES6 features and a number of updates to existing APIs. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux and Chrome OS.

Improved notification capabilities

Chrome 42 allowed users to opt in to receive push notifications from sites even after the page is closed. Sites may now use getNotifications to observe which of their notifications are still being displayed, and to store a payload with a notification so they can determine which notification was clicked.

Promoted add to homescreen improvements

Since Chrome 42, users who frequently visited a high-quality web app on Android saw a banner allowing them to add the site to their home screen in one tap. In this release Chrome fires a cancellable beforeinstallprompt event before the banner is shown, allowing developers to measure user interaction with the feature. Developers are also now able to offer the banner for their native Android app.

ES6 computed property names

Until now, developers defining a JavaScript object literal needed to know the names of all of its properties before runtime. This release increase the expressiveness of the object literal syntax by providing support for ES6 computed property names, allowing developers to put an expression in brackets [], to be computed as the property name at runtime.

let propertyName = "foo";
let obj = {
 [propertyName + "IsTrue"]: true,
 contains: 12

Other updates in this release
  • Chrome’s implementation of the Push API has undergone several minor breaking changes in order to keep up to date with the evolving specification.
  • ES6 extended Unicode escape sequences allow developers to use the extended set of Unicode characters in JavaScript string literals, where previously characters whose escape sequences contain more than four hexadecimal values were unable to be denoted.
  • This release includes a new implementation of multi-column layout by Opera engineer Morten Stenshorne, solving historic issues with incorrect column balancing.
  • Developers should now use the scroll attributes of document.scrollingElement instead of document.body as the latter has several well known issues.

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

Posted by Peter Beverloo, Software Engineer and Notification Newsmaker