All Feeds | XSL | RSS | Embed | Edit

Chrome 60 Beta: Paint Timing API, CSS font-display, and Credential Management API improvements

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Paint Timing API

While no generalized metric perfectly captures when a page is loaded in all cases, First Paint and First Contentful Paint are invaluable numbers to measure critical user moments during loading. To give developers better insight into their site’s loading performance, the new Paint Timing API exposes metrics that capture First Paint and First Contentful Paint.
Screen Shot 2017-06-08 at 8.57.03 AM.png
Stills of a First Paint and First Contentful Paint for Google.com, from “Web Performance: Leveraging the Metrics that Most Affect User Experience” at Google I/O 2017

CSS font-display

Downloadable web fonts are often used to create more visually rich web experiences. Historically, Chrome has delayed rendering text until the specified font is available, to ensure visual correctness. However, downloading a font can take as long as several seconds on a poor connection, significantly delaying the time until a user sees content. Chrome now supports the CSS @font-face descriptor and corresponding font-display property, allowing developers to specify how and when Chrome displays text content while downloading fonts.

Credential Management API improvements

In response to developer feedback and to make the Credential Management API easier to use for all sites, the need for a custom fetch() to access the stored password is now deprecated. Starting in Chrome 60, the user’s password will now be returned directly as part of the PasswordCredential.

In addition, we've made a series of changes to better align with the work being done in the Web Authentication Working Group. This includes the deprecation of requireUserMediation, which has been renamed to preventSilentAccess.

Other features in this release

Deprecations and interoperability improvements



Posted by Shubhie Panicker, Paint Timing Promoter

Improving advertising on the web

Advertising is a critical component of the web, keeping content open and free for everyone. However, over the years we've increasingly heard from users that while some types of advertising are fine, others can seem overwhelmingly frustrating or intrusive. Due to these poor ad experiences, the usage of extensions that block ads across the web continues to rise, up about 30% from just last year. This reduces the ability for publishers to continue creating free content and threatens the sustainability of the web ecosystem.

Chrome has always focused on giving users the best possible experience browsing the web. For example, Chrome, like other browsers, prevents pop-ups in new tabs based on the fact that they are annoying. Today, we have an even better understanding of the types of experiences that bother users when it comes to unwanted advertising. New public, consumer-driven research done by the Coalition for Better Ads in creating the Better Ads Standards outlines a number of these experiences, such as full-page ad interstitials, ads that unexpectedly play sound, and flashing ads. In dialog with the Coalition and other industry groups, we plan to have Chrome stop showing ads (including those owned or served by Google) on websites that are not compliant with the Better Ads Standards starting in early 2018.

We know that many web developers make most or all of their revenue from digital advertising, and we want to make following the guidance of the standard as easy as possible. Starting today we're rolling out the Ad Experience Report, a new tool which provides screenshots and videos of annoying ad experiences we’ve identified to make it easy to find and fix the issues. Developers can also use the report to re-submit their site for review once the problematic ad experiences have been addressed.

This is just one step toward making advertising an excellent experience across the web, and we plan to continue integrating user feedback with developer needs to help balance the web ecosystem for all.

Posted by Rahul Roy-Chowdhury, VP Product Management

Goodbye PNaCl, Hello WebAssembly!

Historically, running native code on the web required a browser plugin. In 2013, we introduced the PNaCl sandbox to provide a means of building safe, portable, high-performance apps without plugins. Although this worked well in Chrome, it did not provide a solution that worked seamlessly across all browsers.


Since then the web community has rallied around WebAssembly, as a cross-browser solution to high performance code. WebAssembly provides the speed necessary to build an in-browser video editor or run a Unity game at a high frame rate utilizing existing standards-based web platform APIs. Applications using WebAssembly already run in multiple browsers: Chrome and Firefox support WebAssembly natively and Edge and Safari support WebAssembly in preview versions of their browsers.


Given the momentum of cross-browser support, we plan to focus our native code efforts on WebAssembly going forward. We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. We believe that the ecosystem around WebAssembly makes it a better fit for new and existing high-performance web apps, and that usage of PNaCl is sufficiently low to warrant deprecation.


We recognize that technology migrations can be challenging. To help ease the transition we have prepared a set of recommendations for existing PNaCl implementations to migrate to the web platform, as well as a feature roadmap for WebAssembly. As you embark on the migration process, please let us know if you run into any challenges, so that we can help make the shift as smooth as possible.


With the launch of WebAssembly, the web platform has gained a foundation for a new generation of fast and immersive web apps that run in any browser. We’re excited to see what developers build next!



Posted by Brad Nelson, Software Engineer on NaCl, PNaCl, and WebAssembly

The Modern Mobile Web: State of the Union

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:

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

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

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


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

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

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.

TMPNOTIF.png
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

Deprecations and interoperability improvements


Posted by Sami Kyostila, Headless Honcho

Next steps toward more connection security

In January, we began our quest to improve how Chrome communicates the connection security of HTTP pages. Chrome now marks HTTP pages as “Not secure” if they have password or credit card fields. Beginning in October 2017, Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode.
Treatment of HTTP pages in Chrome 62

Our plan to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the change in Chrome 56, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we’re ready to take the next steps.

Passwords and credit cards are not the only types of data that should be private. Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the “Not secure” warning when users type data into HTTP sites.

Treatment of HTTP pages with user-entered data in Chrome 62

When users browse Chrome with Incognito mode, they likely have increased expectations of privacy. However, HTTP browsing is not private to others on the network, so in version 62 Chrome will also warn users when visiting an HTTP page in Incognito mode.

Eventually, we plan to show the “Not secure” warning for all HTTP pages, even outside Incognito mode. We will publish updates as we approach future releases, but don’t wait to get started moving to HTTPS! HTTPS is easier and cheaper than ever before, and it enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our set-up guides to get started.

Posted by Emily Schechter, Chrome Security Team

Real-world JavaScript performance

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

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”

Chrome 58 Beta: IndexedDB 2.0, an improvement to iframe navigation, and immersive full screen for PWAs

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

IndexedDB 2.0

The IndexedDB 2.0 standard is now fully supported in Chrome, making it simpler to work with large data sets in the browser. IDB 2.0 features new schema management, bulk action methods, and more standardized handling of failures.



The structure of a site’s database has large performance impacts and can be difficult to change. To simplify updates, object stores and indexes can now be renamed in-place after a refactoring. Sites can also use more natural keys without worrying about a performance penalty thanks to binary keys, which allow compact representations for custom keys.


Data retrieval is easier with the getKey() and openKeyCursor() methods, which also provide better performance when only a database key is needed. The new continuePrimaryKey() cursor method makes it easier to divide large data access across transactions and page loads without worrying about duplicate primary keys. The getAll() and getAllKeys() methods allow bulk recovery of entire datasets without the need for a cursor.

An improvement to iframe navigation

Third-party content, such as advertising, that automatically redirects the page can annoy users and create security issues. Because of this, developers are able to put third-party content inside sandboxed iframes to prevent this behavior. However, in some cases this type of content needs to navigate the top-level page when clicked, like a standard advertisement.

To address this, Chrome 58 now supports the new iframe sandbox keyword allow-top-navigation-by-user-activation. This keyword gives sandboxed iframes the ability to navigate the top-level page when triggered by user interaction, while still blocking auto-redirects.

Immersive full screen for PWAs

When Progressive Web Apps (PWAs) are launched from the Android Home screen, they launch in a standalone app-like mode that hides the omnibox. This helps create an engaging user experience, and frees up screen space for content. However, for even more immersive experiences like games, video players, or other rich content, other mobile UI elements such as the system bars can still be a distraction.


Now PWAs can provide a fully immersive experience by setting display: fullscreen in their web app manifest, which hides non-app UI when the site is launched from the home screen.


         A PWA launched from the home screen (left), launched from the home screen in standalone mode (middle), and launched from the home screen in fullscreen mode (right).

Other features in this release

Deprecations and interoperability improvements


Posted by Victor Costan, IndexedDB Interloper

Faster 3D rendering with WebGL 2.0

The WebGL JavaScript API exposes hardware-accelerated 3D graphics to the web. Chrome 56 brings support for WebGL 2.0, a major upgrade to the API which unlocks a variety of new graphics features and advanced rendering techniques. WebGL 2.0 is currently available for Chrome users with modern graphics hardware on Windows, macOS, and Linux, and is coming soon to Android.


Screen Shot 2017-03-15 at 3.12.13 PM.png
WebGL 2.0 Transform Feedback demo (live link, Github repository)




WebGL 1.0 first launched in Chrome 6 years ago and gave web developers the ability to create immersive plugin-free graphics experiences, from remixing World Cup plays in real-time to visualizing a rock climbing route in a news article. WebGL 2.0 makes it even easier to build 3D web applications, with faster real-time rendering, new types of textures and shaders, and reduced video memory consumption.  Techniques including deferred shading, tone mapping, volumetric effects, and particle effects can now be efficiently implemented. The new APIs also bring WebGL up to feature parity with OpenGL ES 3.0, a graphics platform commonly used in mobile games.


In addition to new rendering capabilities, WebGL 2.0 also introduces a substantially expanded conformance test suite with over 340,000 test cases to help ensure that different web browsers offer compatible graphics platforms. Chrome passes 100% of these test cases across multiple GPU vendors on every desktop platform, ensuring that its WebGL 2.0 implementation is stable and consistent.


To get started using WebGL 2.0, check out the WebGL 2.0 Samples Pack, which contains small self-contained examples of most new API features. You can also see WebGL 2.0 in action in After the Flood1, an interactive demo by PlayCanvas, created in conjunction with Mozilla. Finally, check back here for more news about future graphics features, such as OpenGL ES 3.1 support and explorations into a lower-level web graphics API supporting the new explicit graphics interfaces like Vulkan, Metal, and DirectX 12.


Posted by Zhenyao Mo, Software Engineer



[1] If this demo or other WebGL 2.0 content doesn’t run on your machine, you may need to update your graphics hardware or driver.

Reducing power consumption for background tabs

Efficient power usage is an important aspect of speed, one of Chrome’s key pillars. To prolong battery life, Chrome should minimize power impact from things users can’t see. This includes background tabs,  which consume a third of Chrome's power usage on desktop. Starting in version 57, Chrome will throttle individual background tabs by limiting the timer fire rate for background tabs using excessive power.



Chrome has focused on improving the user experience by throttling tab performance for many years. Like many browsers, Chrome has limited timers in the background to only run once per second. Via the new throttling policy, Chrome 57 will delay timers to limit average CPU load to 1% of a core if an application uses too much CPU in background. Tabs playing audio or maintaining real-time connections like WebSockets or WebRTC won’t be affected.



We've found that this throttling mechanism leads to 25% fewer busy background tabs. In the long-term, the ideal is for background tabs to be fully suspended and instead rely on new APIs for service workers to do work in the background. Chrome will continue to take steps in this direction to prolong users' battery life, while still enabling all the same experiences developers can build today.


Posted by Alexander Timin, Software Engineer and Power Saver

Chrome 57 Beta: CSS Grid Layout, Improved Add to Home screen, Media Session API

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.



CSS Grid Layout

Sites are increasingly being accessed on screens of all sizes, from large LCD TVs to tiny watch faces. Historically, supporting all of these screen sizes required complex combinations of markup and CSS, making code hard to maintain. To give developers more granular control over how elements grow and shrink to fit the current screen size, CSS Grid Layout is now available.




CSS Grid supports a two-dimensional grid-based layout system, optimized for responsive user interface design. Elements within the grid can be specified to span multiple columns or rows. Elements positioned in a CSS grid can also be named, making layout code easier to understand.
Screenshot 2017-01-25 20.06.19.png
CSS Grid allows developers to arbitrarily place elements on a grid with full control over element flow, sizing behavior and responsiveness.

Improved Add to Home screen


Update (2017/03/09): Improved Add to Home screen is now planned to launch in Chrome 58.

Since early versions of Chrome for Android, users have been able to add sites to their Home screen for fast and convenient access. This feature adds the icons using Android shortcuts, which means that web apps don’t show up throughout Android in the same way as installed native apps.




In this release, when a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way. For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.

Media Session API

Media consumption is one of the most common uses for the mobile web. In Chrome for Android, developers can customize the lock screen UI and notifications with media content using the new Media Session API. By providing metadata to the browser about the content being played, developers can create rich lock screen messaging that includes information such as title, artist, album name, and artwork. Additionally , the site is now able to respond to user actions taken on the notification itself, such as seeking or skipping.


media-session-tldr-with-cc.png

Other features in this release

Deprecations and interoperability improvements


Posted by Xi Han, Home Screen Heroine

Integrating Progressive Web Apps deeply into Android

In 2015, we added a new feature to Chrome for Android that allows developers to prompt users to add their site to the Home screen for fast and convenient access. That feature uses an Android shortcut, which means that web apps don’t show up throughout Android in the same way as installed native apps. For example, many developers have asked for their web app to show up in the app drawer section of the launcher. These differences can be confusing for users and prevent the experience from feeling as cohesive as it could.



In the next few weeks we’ll be rolling out a new version of this experience in Chrome beta. With this new version, once a user adds a Progressive Web App to their Home screen, Chrome will integrate it into Android in a much deeper way than before. For example, Progressive Web Apps will now appear in the app drawer section of the launcher and in Android Settings, and will be able to receive incoming intents from other apps. Long presses on their notifications will also reveal the normal Android notification management controls rather than the notification management controls for Chrome.




This new Add to Home screen feature is one more step in our journey to empower developers to build the best possible experience for their users, and we are committed to ensuring the same mechanisms for installing Progressive Web Apps are available to all browsers on Android.


Posted by Yaron Friedman, Add to Home screen aficionado

Open-sourcing Chrome on iOS!

Historically, the code for Chrome for iOS was kept separate from the rest of the Chromium project due to the additional complexity required for the platform. After years of careful refactoring, all of this code is rejoining Chromium and being moved into the open-source repository.



Due to constraints of the iOS platform, all browsers must be built on top of the WebKit rendering engine. For Chromium, this means supporting both WebKit as well as Blink, Chrome's rendering engine for other platforms. That created some extra complexities which we wanted to avoid placing in the Chromium code base.



Given Chrome's commitment to open-source code, we've spent a lot of time over the past several years making the changes required to upstream the code for Chrome for iOS into Chromium. Today, that upstreaming is complete, and developers can compile the iOS version of Chromium like they can for other versions of Chromium. Development speed is also faster now that all of the tests for Chrome for iOS are available to the entire Chromium community and automatically run any time that code is checked in.



We value the open source community and all of our contributors, and we're glad that Chrome for iOS can finally join in.


Posted by Rohit Rao, Upstream Angler

Performance improvements in Chrome's rendering pipeline

Speed is one of Chrome’s four core principles, enabling web developers to provide users with faster, more engaging web experiences. While many components in the browser contribute to overall speed, the rendering pipeline is primarily responsible for ensuring websites display at 60 frames per second (fps), which feels fast and responsive to users. Over the last few months we’ve rolled out several performance improvements to Chrome’s rendering pipeline, making it even smarter about the work it completes. Chrome now more intelligently skips redundant tasks, chooses optimal rendering algorithms, and better utilizes system hardware, causing websites to load faster, run smoother, and use less power.



In order to display content at 60fps, Chrome has only 16ms to render each frame, including JavaScript execution, style, layout, painting, and pushing the resulting pixels to the user’s screen. Of that 16ms time budget, the less Chrome uses, the more time web developers have to run scripts, load content, and delight their users. Many of our recent improvements to the rendering pipeline focus on reducing the per-frame workload, rather than simply improving Chrome’s raw speed.



For example, when Chrome is preparing to paint pixels to the screen, it must first identify which elements on the page need to be redrawn and which can be copied from the previous frame’s cache. On highly dynamic pages with frequent DOM changes, this performance cost can add up quickly. To simplify this task, Chrome now tracks the draw commands generated for each element and can identify visually non-overlapping subsets. If one of these subsets hasn’t been modified, the entire block can be copied directly from the cache without any additional work. This optimization reduces the time it takes to paint a new frame to the screen by up to 35%.



Chrome also groups the pixels into tiles to enable smaller and faster updates to the screen. Previously, Chrome would redraw any of these tiles that had been modified by a DOM update, but this is only optimal if the majority of a tile’s area needs to be redrawn. If only a few pixels have changed, it’s faster to copy the entire tile from the previous frame and then update the new pixels. Chrome can now intelligently choose the redraw pipeline that will be faster, reducing tile redraw time by up to 40%.



 test.gif  
Any update to the screen, such as the input cursor blinking, would previously require the whole tile to be re-rendered (left). When only a few pixels have changed, Chrome can now redraw only the modified region (right).




In addition to intelligently optimizing its workload, Chrome is now better at choosing how it completes that work given the underlying hardware. While video and canvas elements have been GPU accelerated for a long time, Chrome is constantly getting better at utilizing the GPU for more challenging rendering tasks. On Android, Mac, and Windows, Chrome now better utilizes GPU acceleration for complex site content rendering. This improves animation performance, input latency, and scroll smoothness for modern SVG and HTML5 pages.



There are many different dimensions to speed, and we’re committed to continually improving Chrome’s performance and enabling developers to optimize their user experience to hit 60fps. The rendering pipeline is only one piece of the puzzle, and we’ve got a lot more coming. Stay tuned as we continue taking deep dives into performance and steadily make the web faster and more responsive for all Chrome users.


Posted by Chris Harrelson, Painting Professional

Reload, reloaded: faster and leaner page reloads

Reload has long been a staple feature of web browsers and kept its original behavior throughout the years, despite the changing landscape of web platform innovations, connectivity, and content consumption patterns. When reloading a page, browsers will check with the web server if cached resources are still usable, a process known as validation. This typically results in hundreds of network requests per page issued to dozens of domains. On mobile devices, the high latency and transient nature of mobile connections mean that this behavior can produce serious performance issues. In the latest version of Chrome, changes to page reload behavior produce reloads that are 28% faster and result in 60% fewer validation requests.

Users typically reload either because a page is broken or the content seems stale. The existing reload behavior usually solves broken pages, but stale content is inefficiently addressed by a regular reload, especially on mobile. This feature was originally designed in times when broken pages were quite common, so it was reasonable to address both use cases at once. However, this original concern has now become far less relevant as the quality of web pages has increased. To improve the stale content use case, Chrome now has a simplified reload behavior to only validate the main resource and continue with a regular page load. This new behavior maximizes the reuse of cached resources and results in lower latency, power consumption, and data usage.




Despite being a relatively minor change, the new behavior makes reloads up to 28% faster and consume less bandwidth and power. Furthermore, Facebook contacted us with data showing that Chrome was sending validation requests at three times the rate of other browsers. Thanks to the new reload behavior and some related changes, Facebook now reports 28% faster page reloads and 60% less validation requests from Chrome.

We hope this faster reload will come in handy whenever you want to get the latest content on your favorite website or quickly recover from a flaky connection in the subway.

Posted by Takashi Toyoshima, “Reloader Sensei”

Introducing the WebVR API in Chrome for Android

Virtual Reality (VR) is rapidly growing in popularity, and now it's coming to the web. The power of the web is that it can allow VR to work across browsers and hardware, accessible via a single click. This enables VR developers to broadly reach users across multiple types of headsets with a single web app. Here’s how to get started.
Chrome 56 for Android is now available in beta, and web developers can sign up for an Origin Trial which enables the WebVR API and GamePad API extensions. The WebVR API provides access to the input and output capabilities of virtual reality devices such as Daydream View. It also provides access to the user’s position and orientation, so that web apps can render a stereoscopic 3D scene to the headset's display. The Gamepad API extensions provide access to input from motion controllers, such as the Daydream controller, and enables natural interactions in VR.
Origin Trials allow a developer to temporarily enable the feature for all Chrome users visiting their website. The WebVR API is still evolving and will undergo further changes based on developer feedback before being enabled by default for all pages. WebVR will be extended to desktop platforms and Google Cardboard in a future Chrome release, and several performance improvements are coming in Chrome 57.
To learn how to get started and build your first WebVR web app, visit the WebVR developer site for tutorials and samples. Join the conversation by giving feedback on the API or the Chrome implementation and joining the WebVR Slack channel.
Posted by Brandon Jones, Virtual Reality Plumber

Roll-out plan for HTML5 by Default

Four months ago we announced that we’d be moving to HTML5 By Default to offer a safer, more power-efficient experience. As a reminder, this change disables Adobe Flash Player unless there’s a user indication that they want Flash content on specific sites, and eventually all websites will require the user’s permission to run Flash. To ensure a smooth transition, not all users and sites will be affected immediately. HTML5 by Default and the associated user prompts will be introduced gradually as follows.
The feature will be rolled out to users over a few months. HTML5 By Default will be enabled for 1% of users of Chrome 55 Stable in the next few days. The feature is also enabled for 50% of Chrome 56 beta users. With Chrome 56 stable in February, we plan to enable it for all users.
Starting in January users will be prompted to run Flash on a site-by-site basis for sites that they have never visited before. We want to avoid over-prompting users, so over time we’ll tighten this restriction using Site Engagement Index, a heuristic for how much a user interacts with a site based on their browsing activity. In October all sites will require user permission to run Flash.
More details, including specific Site Engagement Index thresholds, are available on the Flash Roadmap Page. Developers can find recommendations on how to test their Flash sites there as well. As sites transition from Flash to HTML5, this change will no longer affect them and the entire web will become faster, more secure and power-efficient.
Posted by Eric Deily, wrangler of the Default

Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.


“Not Secure” warning for HTTP password and credit card pages


To help users browse safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Starting in version 56, Chrome will mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure. The feature will roll out gradually over the next few weeks.

To avoid being labeled insecure, sites should secure their traffic with HTTPS and follow general security guidelines.

Chrome ‘Not Secure’ warning appearing in the URL bar for a site with an HTTP connection  

Web Bluetooth

Sites can now interact with Bluetooth Low Energy (BLE) devices using the Web Bluetooth API on Android, Chrome OS, and Mac. The Web Bluetooth API uses the GATT protocol, which enables web developers to connect to bluetooth devices such as printers and LED displays with just a few lines of JavaScript. Web Bluetooth can also be combined with Physical Web beacons to discover and control nearby devices. To get started, check out these samples and demos on GitHub.  

heart.gif
An Android device connecting to a BLE-enabled heart rate monitor via the web (source)

CSS position: sticky

Chrome now supports CSS position: sticky, a new way to position elements. A position: sticky element is relatively-positioned, but becomes position: fixed after the user reaches a certain scroll position.

Previously, building content headers that scrolled normally until sticking to the top of the viewport required listening to scroll events and switching an element’s position from relative to fixed at a specified threshold. This solution was difficult to synchronize, resulting in small visual jumps. Now, users can achieve the desired effect by simply positioning their elements as sticky.


Other features in this release

Deprecations and interoperability improvements

Posted by Vincent Scheib, Web Bluetooth Orthodontist

Chrome Dev Summit 2016: The Mobile Web Moves Forward


Last week at the 4th annual Chrome Dev Summit, we were excited to share a glimpse of what’s possible with over 1,000 developers in person, and thousands more on the livestream. Each year this is a time to hear what developers have been building, share our vision for the future of the web platform, and celebrate what we love about the web...


Reach of the web
As we've talked about before, one of the superpowers of the web is its incredible reach. There are now more than two billion active Chrome browsers worldwide, with many more web users across other browsers. The majority of these users are now on mobile devices, bringing new opportunities for us to explore as an industry.

Mobile browsers also lead the way for the internet’s newest users. Exclusively accessing the internet from mobile devices, users in emerging markets struggle with limited computing power, unreliable networks, and expensive data. For these users, native apps can be a poor match due to their large data and storage requirements. And, it’s these constraints that have resulted in the developing markets leading the charge when it comes to innovating on the web.

Progressive

Instead, the web can fill these needs for all users through an experience we've been calling Progressive Web Apps (PWAs). These web apps provide the performance users have come to expect from their device, while also offering critical capabilities such as offlining, add-to-homescreen, and push notifications. We've been encouraged by the strong adoption of these capabilities, with push notifications recently exceeding 18 billion notifications per day across 50,000 domains.


Last year when we spoke about PWAs, things were just getting started. Now we're seeing the movement in full swing, with many large sites across the globe launching great new apps and feeling the success that PWAs can bring.

DAY 1 - THAO LOGOS.png

Alibaba.com, built a PWA and saw a 76% increase in conversion rates across browsers. The investment in the mobile web increased monthly active user rates on iOS by 14 percent. On Android devices where re-engagement capabilities like push notifications and Add to Homescreen were enabled, active user rates increased by 30 percent.


Another great example is The Weather Channel. Since launching a PWA they achieved an 80% reduction in load time and within three months, saw almost 1 million users opt in to receive web push notifications.


During the Summit, we also heard from Lyft, who shared their experience of building a PWA in less than a month, and using less than a quarter of the engineering support needed to build their native app. Learn more about our how partners are using PWA technologies to enhance their mobile web experience.


What can you do?
We also have a variety of tools, libraries, and APIs available to help you bring the benefits of PWAs to your site. For example, Chrome's DevTools provides assistance along every step of the development flow. DevTools has a ton of new features to help you build great mobile apps, such as network simulation, CPU throttling, and a PWA audit tool powered by Lighthouse.


For developers just beginning their web app or looking to rework an existing one, the Polymer App Toolbox provides a set of components and tools for easily building a Progressive Web App using web components. And Polymer 2.0 is right around the corner, making it easy to take advantage of the new Web Components v1 APIs shipping cross-browser and build mobile web apps with minimal overhead.


Finally, checkout can be a complicated process to complete and in the retail sector alone there are 66% fewer conversions on mobile than on desktop. With PaymentRequest, you can now bring a seamless checkout experience to your website with support for both credit cards and Android Pay, increasing odds for conversion.


Catch up
Finally, if you didn’t catch our live stream in real time, you can always check back on our YouTube channel for all the recordings or see the highlights from the event in 57 seconds.


Thanks for coming, thanks for watching, and most of all, thank you for developing for the web!

Posted by Darin Fisher, VP Engineering, Chrome

Here’s to more HTTPS on the web!

Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we’ve worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future. It’s happening now, with secure browsing becoming standard for users of Chrome.


Today, we’re adding a new section to the HTTPS Report Card in our Transparency Report that includes data on how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory.
Percentage pages loaded over HTTPS in Chrome

As the remainder of the web transitions to HTTPS, we’ll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP.


As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we’ve posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.


We’ve seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented “we were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS.” CNET, a large tech news site, had a similar experience. “We successfully completed our move of CNET.com to HTTPS last month,” said John Sherwood, Vice President of Engineering & Technology at CNET. “Since then, there has been no change in our Google rankings or Google organic search traffic.”


Webmasters that include ads on their sites also carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, “saw no material impact to AdX revenue with the transition to SSL.”


As migrating to HTTPS becomes even easier, we’ll continue working towards a web that’s secure by
default. Don’t hesitate to start planning your HTTPS migration today!

Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team

Making Chrome on Windows faster with PGO

Chrome is always looking for ways to speed up the web. Starting in Chrome 53, Chrome has started using Microsoft’s Profile Guided Optimization (PGO) technology to make Chrome up to 15% faster on Windows.

New tab page load time
14.8% faster
Page load (time to first paint)
5.9% faster
Startup time
16.8% faster
PGO impact on load and startup time

Chrome is a huge software project with more than a million functions in its source code. Not all functions are equal - some are called frequently, while others are rarely used.  PGO uses data from runtime execution that track which functions are most common to guide optimization.
To gather this data, the nightly build process now produces a special version of Chrome that tracks how often functions are used. PGO then optimizes those high-use functions for speed, in some cases increasing the binary size of those functions. To balance out that increase, PGO also optimizes less-used functions with smaller, though slightly slower code. These trade-offs result in higher overall performance, and a smaller overall code footprint.
PGO also optimizes the memory location of the code, moving rarely-used functions away from frequently-used ones in memory.  This results in more optimal use of the CPU instruction cache by avoiding caching of less-used code, increasing overall performance. There are many other tricks that PGO uses to make Chrome faster, and they add up to great results.
64-bit Chrome on Windows is using PGO as of version 53, and 32-bit Chrome is using it as of version 54.  Try out the latest version of Chrome to see the difference with PGO.
Posted by Sébastien Marchand, who is Pretty Good at Optimizing.

Chrome 55 Beta: Input handling improvements and async/await functions


Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Input handling improvements

As usage of the mobile web grows, it is increasingly important for sites to react well to touch input. Historically, this meant handling MouseEvent and TouchEvent separately, which can be difficult to maintain. Chrome now enables unified input handling by dispatching PointerEvents. PointerEvents lead to more responsive pages, as they don’t block scrolling by default. To achieve the same performance with TouchEvent, pages can use passive event listeners.


Chrome also now supports two new ways to respond to input. The touch-action CSS property enables sites to react to gestures such as panning. For mouse buttons, the new auxclick input event type allows sites to manage the click behavior of non-primary buttons.   

Async and await functions

Asynchronous JavaScript can be difficult to reason about. Promises help avoid the nesting problem of callbacks, but Promise-based code can still be difficult to read when a site has large chains of asynchronous dependencies. Chrome now supports the async and await JavaScript keywords, allowing developers to write Promise-based JavaScript that can be as structured and readable as synchronous code.


Fetching a URL and logging the response using Promises:

function logFetch(url) {
 return fetch(url)
   .then(response => response.text())
   .then(text => {
     console.log(text);
   }).catch(err => {
     console.error('fetch failed', err);
   });
}


The same code using async and await:

async function logFetch(url) {
 try {
   const response = await fetch(url);
   console.log(await response.text());
 }
 catch (err) {
   console.log('fetch failed', err);
 }
}

CSS automatic hyphenation

Formatting text to fill available space can be a challenge across devices and screen sizes. Chrome now supports CSS automatic hyphenation, one of Chrome’s most frequently requested layout features, on Android and Mac. CSS hyphenation allows the browser to hyphenate words when line-wrapping, improving the visual consistency of text blocks. Hyphenation support will be extended to other platforms in future releases.

hyphenation-gif-2.gif
A paragraph rendered with and without automatic hyphenation

Other features in this release

  • The once event listener option enables callbacks to be invoked only once before removing the event listener.
  • Sites can now mark web storage as persistent, preventing Chrome from automatically clearing storage for that site.
  • Cross-origin iframes now require a user gesture to start audio playback using the Web Audio API on Android, matching the behavior of the <audio> and <video> elements.
  • The TLS stack now implements GREASE, a mechanism to help prevent problems with buggy TLS servers.
  • Developers can create a MediaStreamTrackEvent in an alternative way with its new JavaScript constructor.
  • RSA-PSS signature algorithms have been added to TLS to prepare for TLS 1.3.
  • To improve load times and prevent failed navigations, cross-origin and parser-blocking scripts injected using document.write() will no longer load over 2G connections.
  • AudioNode constructors of the form new AudioNode(context, options) are now available, making it simpler to manage audio from scripts.
  • When the media player is too narrow to show every button, an overflow menu will appear to provide the hidden functionality to users.
  • Chrome media controls will now display a download button when the playback is associated with a file that can be downloaded.
  • The Web Share API is available for experimentation as an origin trial.

Deprecations and interoperability improvements

  • BaseAudioContext will replace AudioContext in the Web Audio API to conform to spec.
  • CSS Clipping Path properties no longer require the webkit prefix.
  • The MediaStream constructor is now available without prefix alongside the existing webkitMediaStream.
  • Non-script MIME types will no longer trigger script execution.
  • <textarea maxlength=""> and <textarea minlength=""> have been updated to count each line break as one character, instead of two.
  • The webkit prefix has been removed from the imageSmoothingEnabled property of CanvasRenderingContext2D.

Posted by Dan Ehrenberg, Asynchronous Adventurer