Chromium Blog

The Modern Mobile Web: State of the Union

Thursday, May 18, 2017

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

What a difference a year makes. Last year at Google I/O, we shared that the mobile web was open for business. New technologies such as AMP and Progressive Web Apps (PWAs) were bringing new capabilities, better performance, and a streamlined workflow to the mobile web.

Fast forward one year later: more than two billion AMP pages have been created and "PWA" has proved to be far more than a buzzword—it’s now the way that many businesses around the world are building for mobile devices. For more details, take a look at the video from Google I/O on the latest mobile web state of the union, or read below on how these technologies are making the modern mobile web mainstream.

Momentum Summing up all the great success stories from around the world in a single post is a tall order, but here are some highlights.

To improve the performance of Wego's mobile site, the company built AMP pages using amp-install-serviceworker to transition to a fast PWA experience. Average page load time decreased from 12 seconds to less than one second, and conversion rates increased by 95%.

When Forbes rebuilt their mobile website as a PWA, they began by re-thinking what their experience could look like on a phone. Instead of minimally updating their underlying site, Forbes integrated PWA technologies to provide an immersive, app-like experience. They saw immediate improvements and engagement rates have more than doubled since launch.

Ola, the leading cab aggregator in India, built a PWA and noticed that 20% of users who book using their PWA had previously uninstalled their app. By reducing the amount of storage space needed, the PWA allowed them to effectively re-engage with users that otherwise would have been lost.

Another success story is Twitter Lite, a PWA which minimizes data usage, is resilient on unreliable mobile networks, and is less than 1MB of space on a device. Twitter's new mobile experience is also optimized for speed, with up to 30% faster launch times as well as quicker navigation throughout the site. They've found that users are spending 2.7x more time on site, and as a result are seeing 76% more tweets on the new PWA than their previous mobile site. Twitter is seeing incredible re-engagement with 1 million sessions initiated a day from icons added to the Android homescreen.

Polished Experiences Users expect a lot from their mobile devices, and we've added tons of APIs over the past year to meet that demand. The mobile web can support more use cases and get more done than ever before. A few highlights:

Improved Add to Homescreen

Earlier this year we unveiled Improved Add to Homescreen, integrating PWAs much deeper into the Android operating system. Now, in addition to being displayed on the homescreen, PWAs are also displayed in the app launcher and Android settings alongside native apps, and can also open in response to users clicking links in Chrome or other apps.

Payments

Checkout can be a complicated process. To improve payment flows on the web, we launched a one-tap payment API called Payment Request. Using this API allows web apps to support credit cards and Google payment mechanisms such as Android Pay. We also just announced that it is now possible to integrate this API with additional payment apps.

Media Consumption

Over 70% of internet traffic is video. To allow great mobile web media experiences we have given the users more control over playback with the Media Session API, improved full screen playback with the Screen Orientation API, and we’re filling out features for offline with Background Fetch. To learn more, see our mobile web media best practices and see how the APIs can come together at our PWA for Media demo.

Tooling We’ve also been working hard to improve and extend the set of tools that let you build engaging experiences on the web.

Lighthouse is a new automated tool for measuring the quality of a web experience. It runs nearly 100 audits against your web app, checking everything from page performance, to byte efficiency, to accessibility, and gives you a summary score. New integration with Chrome's DevTools means you’ll be able to run Lighthouse audits without leaving the browser.

Polymer 2.0 is the next major release of the Polymer library, re-built from the ground up to take advantage of the best new features of the modern web platform. This release uses new Web Component API’s that have shipped in Chrome and Safari. It’s completely modular and best of all - it’s now 10% faster and 80% smaller.

Chrome is committed to making sure that you can develop easily, engage with your users, and build a thriving business around the web. For the latest news, subscribe to our YouTube channel and follow us on Twitter @ChromiumDev.

Happening now: The Mobile Web State of the Union

Wednesday, May 17, 2017

Welcome to Google I/O 2017! Today at 4PM Pacific Daylight Time, Rahul Roy-chowdhury, VP Product Management for Chrome, will be on stage at Google I/O discussing The Mobile Web: State of the Union. Tune into the livestream below, and if you happen to be attending Google I/O, be sure to come to the Amphitheatre to see it live!

Posted by Ryan Schoen, Product Manager

Improving extension security with out-of-process iframes

Monday, May 8, 2017

Security is critical to Chrome, and many features protect Chrome users as they browse the web. Google Safe Browsing warns users away from websites known to be dangerous. Chrome’s sandbox and multi-process architecture provide additional layers of defense by helping block malware installation and reducing the severity of vulnerabilities. In Chrome 56, we've added yet another layer of defense by fully isolating Chrome extension privileges from web pages.

Chrome has always kept extensions and web pages in different processes where possible, but sometimes extensions host web content in iframes. For example, an extension's options page may include social network buttons or ads. Until recently, these web iframes ran inside the extension's process. This is usually safe because security checks inside that process do not allow web iframes to use extension APIs. However, in rare cases malicious web iframes could exploit bugs to bypass these checks and use the same privileged APIs that are available to extensions, like chrome.history.

Chrome now uses out-of-process iframes to ensure that extension-hosted web iframes are never put into their parent extension process. Even if an extension's web iframe finds a Chrome bug and takes over its own web process, that process won't have access to extension APIs.

With this launch, web iframes in extension pages now run in a separate process from the extension, adding an extra layer of protection to privileged APIs.

Introducing out-of-process iframes will greatly strengthen Chrome's security model, though building them required a large change to Chrome's architecture affecting systems like painting, input events, and navigation. This launch is just the first phase of our Site Isolation project, so stay tuned for even more security improvements that out-of-process iframes make possible.

Posted by Charlie Reis, Site Isolator

Chrome 59 Beta: Headless Chromium, native notifications on macOS, and service worker navigation preload

Tuesday, May 2, 2017

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows. Headless Chromium Headless Chromium allows running Chromium in an automated environment without a user interface or peripherals. This enables use cases such as automating unit tests with Selenium and converting a web page into a PDF.

Headless Chromium is powered by all the modern web platform features provided by Chromium and Blink. Support is now available on Mac and Linux, with a Windows implementation coming soon. Native notifications on macOS Chrome has historically included its own notification system for web and extension developers to send notifications to users. In response to macOS introducing its own rich notification system, many users have asked for the two systems to be integrated.

In Chrome 59, when developers send notifications via the Notifications API or chrome.notifications, they will be shown directly by the macOS native notification system. This change improves the user experience, but some low-usage API features are now discouraged since they result in a degraded experience on macOS, as documented in the migration guide.

Chrome notifications before and after integration with the native notification system.
Service worker navigation preload The Service Worker navigation preload API enables the browser to preload navigation requests while a service worker is starting up. These requests are started before executing the fetch event handler in the service worker intercepting the target URL. This gives the worker access to the preload response inside the fetch event handler, allowing the service worker to handle the navigation with minimal delay. Other features in this release

Developers can now use MediaError.message to obtain greater detail about a MediaError produced by <audio> or <video>.

WritableStreams are now available as part of the Streams API for processing streams of data, while providing a standard abstraction for writing streaming data to a sink with built-in backpressure and queuing.

The Streams API has been expanded with the ability to pipe between ReadableStreams and WritableStreams via the pipeTo() and pipeThrough() methods, allowing easier consumption of streaming data.

Developers can now use the getInstalledRelatedApps function to smartly consolidate push notifications between related web and native apps by suggesting when and on which platform to offer them.

The Image Capture API now allows sites to take higher resolution images than before, providing full control over camera settings such as zoom, ISO, and white balance.

To provide enhanced privacy, CSS stylesheets can now specify their own referrer policy via the HTTP header, rather than always inheriting the referrer policy of the document that originally referenced it.

To avoid over-prompting users, Chrome will now temporarily stop an origin from requesting a permission following the third dismissal of that permission request.

Touch events are now aligned to requestAnimationFrame, ensuring that input is processed as part of the document lifecycle and creating a more efficient and adaptive input response.

The new worker-src Content Security Policy directive restricts which URLs may be loaded as a Worker, SharedWorker, or ServiceWorker.

The Presentation Receiver API is now available, enabling a web page to be presented and developers to interact with the presenting web page.

Deprecations and interoperability improvements

The <dialog> element has changed from display: inline to block by default to better align with the spec.

Following removal from the Media Queries spec, support for hover: on-demand and any-hover: on-demand media queries have been removed.

To better align with spec and help avoid race conditions, decodeAudioData now detaches the given ArrayBuffer before decoding, removing all content from the object and making it unable to be reused or examined.

To increase security, Chrome no longers supports requesting notification permission over HTTP.

The -internal-media-controls-cast-button CSS selector has been removed in favor of the Remote Playback API.

The -internal-media-controls-text-track-list* CSS selectors have been removed in favor of custom-built video controls.

The SVGTests.requiredFeatures attribute has been deprecated following its removal from the spec.

initDeviceMotionEvent() and initDeviceOrientationEvent() were removed in favor of DeviceOrientationEvent() and DeviceMotionEvent(), following a spec trend of moving away from initialization functions and toward constructors.

To preserve consistency across browsers, the sample property will now be included in a violation report (and associated SecurityPolicyViolationEvent object) if a report-sample expression is present in the violated directive.

To increase security, Chrome will now block requests for subresources that contain embedded credentials, and instead handle them as network errors.

To increase security, Chrome will now block requests from HTTP/HTTPS documents to ftp: URLs.

To preserve consistency across browsers, injecting JavaScript via AppleScript is longer supported in Chrome for Mac.

The ability to call Notification.requestPermission() from non-main frames has been deprecated to align the requirements for notification permission with requirements for push notifications, and ease friction for developers. 

Support for Shared Dictionary Compression (SDCH) has been disabled until a stable API has been standardized.

Posted by Sami Kyostila, Headless Honcho

Next steps toward more connection security

Thursday, April 27, 2017

began our questIncognito mode

Treatment of HTTP pages in Chrome 62Our planchange in Chrome 56

Treatment of HTTP pages with user-entered data in Chrome 62alleasier and cheaper than ever beforeset-up guidesPosted by Emily Schechter, Chrome Security Team

Real-world JavaScript performance

Wednesday, April 12, 2017

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

Tuesday, April 11, 2017

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 g.co/reportbadreflow, and designing your websites or services with a no-reflow mindset.

Posted by Steve Kobes, “The Unbouncer”