Posted by Darin Fisher, VP Engineering, Chrome 

The last sessions of the Chrome Dev Summit 2015 are coming to a close, so it’s the perfect time to reflect on the event. We started our annual summit back in 2012, where we first introduced Chrome on Android. Today, there are more than 800 million monthly active users on Chrome for Android. 

The greatest power of the Web is in its reach—not just across devices and operating systems, but in reaching users. Top mobile web properties are seeing 2.5 times the number of monthly unique visitors compared to the top mobile apps, and mobile web reach is growing at more than twice the rate of mobile app reach. This reach offers a unique opportunity to engage with more users.  

We believe this is a pivotal moment for the web platform, as early adopters of a set of key enabling technologies and tools are seeing success. During the keynote, we covered the evolution of the mobile platform and the shift towards “progressive web apps,” which are fast, robust, app-like experiences built using modern web capabilities. The web has come a long way, and building immersive apps with web technology on mobile no longer requires giving up properties of the web you’ve come to love. Flipkart’s new mobile web experience is a great example of a progressive web app that uses the new capabilities to provide a next-generation user experience.

In practice, progressive web apps have three main aspects that separate them from traditional websites: reliability, performance, and engagement.

Every web app should load quickly, regardless of whether a user is connected to fast Wi-Fi, a 2G cell network, or no connection at all. We envision service workers as the ideal way for developers to build web apps that are resilient despite changing and unreliable networks. We've released two libraries to help take the work out of writing your own service worker: sw-precache and sw-toolbox for your App Shell and dynamic content, respectively. Once your implementation is up and running, you can easily test it on different network connections using Chrome DevTools and WebPageTest. Service workers are already seeing great adoption by developers: there are currently 2.2 billion page loads a day using service workers, not counting its use in the New Tab page in Chrome.

The RAIL performance model helps you figure out what a user expects from each interaction with your site or app, breaking down performance into four key goals: 
  • Responses (tap to response) should be less than 100ms 
  • Animations (scrolling, gestures, and transitions) should run at 60 frames per second
  • Idle time should be used to opportunistically schedule non-essential work in 50ms chunks
  • Loading should be finished in under 1 second
In practice, we've found improving even just one area of RAIL performance can make a dramatic difference on the user experience. For example, a one second difference in loading time can have as much as an 11% impact on overall page views and a 16% impact on customer satisfaction.

Traditionally, users have had a hard time re-engaging with sites on the web. Push notifications enable you to build experiences that users can engage with "outside of the tab"--they don’t need to have the browser open, or even be actively using your web app, in order to engage with your experience. Best of all, these notifications appear just like other app notifications. Currently we’re seeing over 350 million push notifications sent every day in Chrome, and it’s growing quickly. Beyond the Rack has found that users arriving to their site by push notifications browse 72% longer than average users and spend 26% more.

Tools for Success
Finally, Google is committed to making web developers successful. As our generalized library for building components on the web, Polymer is also deeply focused on helping developers achieve RAIL. Since its 1.0 release at Google I/O earlier this year, it has grown to be used on over 1 million web pages, including more than 300 projects within Google. Polymer 1.0 was 3 to 4 times faster than the previous 0.5 version, and the latest 1.2 release is even 20% faster than that. To get started with this modern way of thinking about web development, take a quick tour of Polymer, watch the Polymer Summit talks, check out the Polymer codelabs, or try the Polymer Starter Kit.

We already have great resources like Web Fundamentals that we continue to expand and improve.  We’re also committed to documenting each new feature we ship on the Mozilla Developer Network. In the past year alone, we’ve made 2,800 individual edits to MDN and created 212 new pages. To further our commitment to educating web developers, we’ve partnered with Udacity to offer a senior web nanodegree, an education credential focused on modern web technologies and techniques like service workers, Promises, HTTP/2 and more. 

For all the details on Chrome Dev Summit 2015, you can watch full session videos, 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!

The newest Chrome Beta channel release includes support for cooperative multitasking, splash screens for sites added to home screen, flexible desktop notifications, security fixes, and more. Unless otherwise noted, changes described below apply to Chrome for Android, Chrome OS, Linux, Mac, and Windows.

Splash screens on Android

Mobile devices are typically less powerful than desktops, meaning apps can take a few seconds to load. Splash screens allow apps to show something meaningful to users as the app loads, improving perceived performance. The new version of Chrome for Android brings splash screens to web apps when a site is launched from the Android home screen. The splash screen is shown immediately, even while Chrome itself is loading. Developers can customize the splash screen by setting a name, icon, background color, and notification bar color in the web app manifest. The splash screen disappears once the web app begins to draw to the screen, providing a more polished loading experience.

Cooperative multitasking with requestIdleCallback()

To achieve a screen refresh rate of 60 frames per second, developers must guess when performance-critical tasks like rendering will finish and use timers to schedule around them. Unfortunately, developers can’t guarantee that low priority work won’t hurt performance because events like scrolling cannot be predicted. Now developers can explicitly set work to run during idle time using requestIdleCallback(). Functions registered with requestIdleCallback() are given a deadline and can return before that limit is reached to avoid jank. The function can register for another requestIdleCallback() to continue work during the next idle period.

Auto dismissing notifications

Push notifications have been enabled by service workers since Chrome 42. Sites such as social media or email can generate a large number of push notifications that take up screen space and aren’t particularly relevant unless viewed soon after posting. The new version of Chrome now allows developers to configure automatic dismissal of desktop notifications, improving the experience for these kinds of notifications. Sites can set NotificationOptions.requireInteraction to indicate the notification should remain onscreen until the user dismisses it.

Other updates in this release

Posted by Ross McIlroy, Scheduling Samurai

This past spring, Chrome began supporting push notifications for web pages via the emerging web push standard. However, notifications in Chrome aren’t new; Chrome apps and extensions have supported push notifications on desktop since 2010. In some cases, these desktop notifications would appear while users were gone, so in 2013 Chrome launched the notification center, a place for users to find notifications from Chrome apps and extensions that they’d missed. 

However, in practice, few users visit the notification center. To keep Chrome simple, it will be removed from Windows, Mac, and Linux in the upcoming release. The notification center on Chrome OS will remain unchanged.

The new notifications documentation reflects changes that will affect Chrome app and extension developers who send notifications to the center. Notifications sent solely to the notification center will now result in an error, and API events tied to the center will no longer fire. All other notifications will continue to work without requiring any changes.

With the growth of web push, notifications are an increasingly important way for users to engage with web pages they care about. By streamlining the experience on desktop, Chrome can ensure a simple notification experience on every platform.

Posted by Justin DeWitt, Software Engineer

When we launched the Chrome Web Store Support Tab in 2012, our goal was to provide a communication channel that would enable you to have an open discussion with the users of your apps and extensions. Developers like you have reported that the tool has helped identify bugs faster, obtain ideas for new features, and prioritize work based on user impact. But we’ve also seen that many users continue to leave their feedback in the form of comments under the Reviews tab. Until now, the Web Store has not provided an option to respond to these comments, which has had the effect of leaving many users’ bug reports and feature suggestions unanswered, even after the issues have been addressed.

Today, we’re providing both you and your users the ability to reply to comments in the Reviews tab, in order to ensure that you can openly and clearly communicate about all relevant feedback.


To strengthen relationships with your users and ensure that the Reviews tab provides accurate information about your product, we recommend that you begin closely monitoring user reviews for bug reports and feature suggestions. Be sure to reply constructively to both negative and positive reviews, notify users when you have addressed their feedback, and thank the users who are your biggest advocates.  

Before replying to user reviews, please read the commenting guidelines to ensure that your use of this feature is compliant with Chrome Web Store policies. Also remember that when posting reviews, your name and Google account will be shown publicly so that prospective users can see that you consistently provide high quality customer support. Head over to your reviews tab and start connecting with users today!
Posted by James Wagner, Product Lead and Reviews Wrangler

The newest Chrome Beta channel release includes new CSS animation features, improved performance controls, and a large number of API tweaks. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

Animating objects along author specified paths

Previously, animating objects along an author-specified path required complex javascript code that could block important events like rendering and input. Developers can now animate any graphical object along an arbitrary path declaratively as a CSS property, allowing simpler code that doesn’t block rendering or input.

Complex animations using CSS

Optimized image loading and service worker instrumentation

Tools like srcset allow developers to serve an optimized image variant in a responsive way, but it can be cumbersome and inefficient to use in practice. Developers can now negotiate with the server to download the best image variant for a device using straightforward HTTP request headers. These headers communicate DPR, Viewport-Width, and the intended display width of the resource being fetched to the server.

In addition to improving image loading, developers can now instrument service workers to gather detailed fetch and script timing. Developers can also measure the startup time of service workers more accurately.

Other updates in this release

Posted by Eric Willigers, Software Engineer and Animations Acrobat