This morning, Adobe announced their plans to end support for Flash in late 2020. For Flash developers this will mean transitioning to HTML, as Chrome will increasingly require explicit permission from users to run Flash content until support is removed completely at the end of 2020.

HTML is faster, safer, and more power efficient than Flash and works across desktop and mobile. Three years ago, over 80% of Chrome daily desktop users visited sites with Flash. Today only 17% of users visit sites with Flash and we’re continuing to see a downward trend as sites move to HTML.

Over a three-year period, Flash usage has declined 80%.

We strongly encourage sites that still rely on Flash to make the move to HTML as there will be an increasing number of restrictions on Flash leading up to the end of support:

• For sites that use Flash for gaming, a list of relevant APIs and demos can be found at OpenWebGames.com. We recommend exploring technologies like WebAssembly, which allows for high-performance computing.
• For sites that use Flash for media, Mozilla’s media migration guide gives an overview of the APIs used to prepare, distribute and play media on the web.
• Finally, for sites that use Flash for advertising, we recommend switching to HTML ads. Please work with your ad provider directly for this.

Flash helped make the web a rich, dynamic experience, and shaped the modern set of web standards. We recognize that any transition can have challenges, but we will continue to work closely with Adobe and the web community to ensure that users have a great experience and to help developers make the web transition to HTML.

Posted by Anthony Laforge, on behalf of the Chrome team

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.

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

• The Payment Request API is now supported on desktop versions of Chrome.
• Sites can now collect payments through native Android payment apps using the Payment Request API.
• Object rest & spread properties are now supported, making it simpler to merge and shallow-clone objects and implement various immutable object patterns.
• The new Web Budget API enables sites with the Push Notification permission to send a limited number of push messages that trigger background work such as syncing data or dismissing notifications the user has handled on another device, without the need to show a user-visible notification.
• The new Web Push Encryption format is now supported and PushManager.supportedContentEncodings can be used to detect where it can be used.
• PushSubscription.expirationTime is now available, notifying sites when and if a subscription will expire.
• To improve performance and predictability,  pointermove and mousemove events are now delivered once per AnimationFrame, matching the current functionality of scroll and TouchEvents.
• The :focus-within CSS pseudo-class is now available, affecting any element the :focus pseudo-class affects, as well as any element with a descendant affected by :focus.
• The CSS frames timing function is now available, making it useful for animation loops where the animation should display all frames for exactly the same length, including its first and last frames.
• To provide an enriched way to capture editing actions, InputEvent now allows user input to be managed by script, enhancing the details provided to editable elements.  
• To increase security, a BeforeUnload dialog triggered when the user leaves a site will now only be shown if the frame attempting to display it has ever received a user gesture or user interaction, though the BeforeUnloadEvent will still be dispatched regardless.
• VP9, an open and royalty-free video coding format, can now be used with the MP4 (ISO BMFF) container and requires the new VP9 string format mentioned below.
• A new VP9 string format is now available and accepted by various media-related APIs, enabling developers to describe the encoding properties that are common in video codecs, but are not yet exposed.

Deprecations and interoperability improvements

• getElementsByTagName() now accepts qualified names in response to an update to the DOM specification.
• /deep/ now behaves like the descendant combinator, which is effectively a no-op.
• To improve user experience, calls to Navigator.vibrate() now immediately return false if the user hasn't explicitly tapped on the frame or any embedded frame, matching existing behavior for cross-origin iframes.
• WEBKIT_KEYFRAME_RULE and WEBKIT_KEYFRAMES_RULE have been removed in favor of the unprefixed standardized APIs, KEYFRAME_RULE and KEYFRAMES_RULE.
• Support for non-standard WebKitAnimationEvent and WebKitTransitionEvent has been removed from document.createEvent().
• To better align with spec, NodeIterator.filter and TreeWalker.filter no longer wrap JavaScript objects, and .prototype has been removed from window.NodeFilter.
• RTCPeerConnection.getStreamById() is being removed, and a polyfill is recommended as a replacement.
• SVGPathElement.getPathSegAtLength() has been deprecated as it has been removed from the SVGPathElement spec.
• Headers.prototype.getAll() has been removed from the Fetch API in line with its removal from the spec.

Posted by Shubhie Panicker, Paint Timing Promoter

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

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

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.

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

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