In order to ensure a smooth, snappy experience when browsing in Chrome, it’s essential to free unused memory. The garbage collector in the V8 JavaScript engine has been optimized to reclaim memory as quickly as possible to shorten pauses to the main thread of execution. But even small pauses can cause jank when they happen at inopportune moments and block important events like clicks, scrolls, or animation frames. To make garbage collection less noticeable, we’ve integrated Blink’s task scheduler into V8 (starting in M41), so that pauses can be not just short, but intelligently scheduled during moments when the browser is idle. New knowledge of completely inactive pages (such as background tabs), also allows V8 to free larger chunks of memory all at once.  The result is reduced jank when browsing and lower memory usage overall.
Scheduling garbage collection tasks (red) in otherwise idle periods (blue).


Smarter garbage collection makes 3D animations and games play smoothly with reduced lag and stuttering. The new task scheduler integration into V8 provides higher frame-rates more consistently for gameplay and rendering. Between Chrome 41 and Chrome 46, our score for the 3D benchmark OORT Online, which measures smooth rendering of WebGL graphics, increased by up to 33%, just shy of the maximum 10,000 points on a modern desktop.

Memory reduction from the new system is particularly pronounced when the browser is idle for a few minutes or more. Leaving a Gmail tab unused for 2.5 minutes, for example, reduces memory consumption by up to 45% between Chrome 45 and previous versions!

In addition to providing a smoother, faster browsing experience for the user, these changes empower developers to push the limits of Chrome with more powerful applications and better graphics. Stay tuned for more V8 optimizations and check out our deep dive into garbage collection timing on the new V8 blog for more details.


Presentation API
Historically, sites have been unable to present content to nearby devices, which made it hard to build experiences like a slide “presenter mode” for the mobile web. The latest release of Chrome on Android now allows mobile sites to present to Google Cast devices using the standards-based Presentation API and the Cast Web SDK.

Custom buttons on notifications
Chrome 42 introduced the ability for users to receive push notifications from websites, allowing users to build deeper relationships with the sites they love. Usage of the feature has grown quickly, with Chrome now delivering more than 350 million push notifications every day. In the latest Chrome release, sites can now add custom buttons to notifications, enabling users to complete tasks entirely within the notification.

Notification actions in Chrome 48 on Android

Detecting maximum connection speed
A user’s mobile phone connects to the internet over anything from high quality WiFi to 2G, which has made it difficult to design the right mobile experience. Developers can now use NetworkInformation.downlinkMax to detect a device's maximum bandwidth so they can send the optimal resources for the connection speed. Sites can also respond to changes in connection quality using the NetworkInformation.onChange event handler.

Other features in this release

Minor changes

Posted by Anton Vayvod, Presentation MC
Labels:



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

 Reliability
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.

 Performance
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.

 Engagement
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!

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
Labels: