Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 84 is beta as of May 28, 2020.

Web OTP API

The Web OTP API (formerly called the SMS Receiver API) helps users enter an OTP on a web page when a specially-crafted SMS message is delivered to the user's Android phone.
When verifying the ownership of a phone number, it is typically done by sending a one-time-password (OTP) over SMS which must be manually entered by the user (or copied and pasted). This manual user flow requires directing the user to the native SMS app and back to their web app with the code. With the Web OTP API, developers can help users enter the code with one tap.
For more information, see Verify phone numbers on the web with the Web OTP API.

Web Animations

Animations on the web help users navigate a digital space, help users remember your app or site, and provide implicit hints around how to use your product. Now, developers have greater control over web animations with the Web Animations API.
Although parts of the API have been around for some time, the new implementation in Chrome is a milestone in its development. In addition to greater spec compliance, Chrome now supports compositing operations, which control how effects are combined and offers many new hooks which enable replaceable events. Additionally, the API now supports Promises, which allow for animation sequencing and for greater control over how animations interact with other app features.
For more information and instructions for using web animations, see Web Animations API improvements in Chromium 84.

Origin Trials

This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

New Origin Trials

Cookie Store API

The Cookie Store API exposes HTTP cookies to service workers and offers an asynchronous alternative to document.cookie.

Idle Detection

The Idle Detection API notifies developers when a user is idle, indicating such things as lack of interaction with the keyboard, mouse, screen, activation of a screensaver, locking of the screen, or moving to a different screen. A developer-defined threshold triggers the notification. For more information, see Detect inactive users with the Idle Detection API.

Origin Isolation

Origin isolation allows web developers to opt in to giving up certain cross-origin same-site access capabilities—namely synchronous scripting via document.domain, and calling postMessage() to WebAssembly.Module instances. This gives the browser more flexibility in implementation technologies. In particular, Chrome now uses this as a hint to put the origin in its own process, subject to resource or platform limitations.
Site isolation, i.e. process-per-site, is the current state of the art in protecting websites from each other. Certain legacy features prevent us from aligning this protection boundary with the origin boundary. Origin isolation allows developers to voluntarily give up these legacy features, in exchange for better isolation.

WebAssembly SIMD

WebAssembly SIMD exposes hardware SIMD instructions to WebAssembly applications in a platform-independent way. The SIMD proposal introduces a new 128-bit value type that can be used to represent different types of packed data, and several vector operations that operate on packed data.
SIMD can boost performance by exploiting data level parallelism and is also useful when compiling native code to WebAssembly.

Completed Origin Trials

The following features, previously in a Chrome origin trial, are now enabled by default.

Content Indexing API

The Content Indexing API, now out of its origin trial, provides metadata about content that your web app has already cached. More specifically, it stores URLs for HTML documents that display stored media. The new API lets you add, list, and remove resources. Browsers can use the information in the index to display a list of offline-capable content. For more information, read Indexing your offline-capable pages with the Content Indexing API.

Wake Lock API Based on Promises

The Wake Lock API has been updated with promises. The Wake Lock API brought a standard, secure, and safe way to prevent some device features such as the screen or CPU cycles from going into power saving state. This update addresses some of the shortcomings of the older API which was limited to screen Wake Lock and didn't address certain security and privacy issues.

Other Features in this Release

App shortcuts

To improve users' productivity and facilitate re-engagement with key tasks, Chrome now supports app shortcuts in Android. They allow web developers to provide quick access to a handful of common actions that users need frequently. For sites that are already Progressive Web Apps, creating shortcuts requires only adding items to the web app manifest. For more information, see Get things done quickly with app shortcuts.

Autoupgrade Image Mixed Content

"Mixed content" is when an HTTPS page loads content such as scripts or images over insecure HTTP. Previously, mixed images were allowed to load, but the lock icon was removed and, as of Chrome 80, replaced with a Not Secure chip. This was confusing and did not sufficiently discourage developers from loading insecure content that threatens the confidentiality and integrity of users' data. Starting in Chrome 84, mixed image content will be upgraded to https and images will be blocked if they fail to load after upgrading. Auto upgrading of mixed audio and video content is expected in a future release.

Blocking Insecure Downloads from Secure (HTTPS) Contexts

Chrome intends to block insecurely-delivered downloads initiated from secure contexts ("mixed content downloads"). Once downloaded, a malicious file can circumvent any protections Chrome puts in place. Furthermore, Chrome does not and cannot warn users by downgrading security indicators on secure pages that initiate insecure downloads, as it does not reliably know whether an action will initiate an insecure download until the request is made.

User-visible warnings will start in Chrome 84 on desktop with plans to block insecure downloads completely in Chrome 88. Warnings will not appear in Android until Chrome 85. For details, see Protecting users from insecure downloads in Google Chrome.

ReportingObserver on Workers

The ReportingObserver API, added in Chrome 69, provides a JavaScript callback function invoked in response to deprecations and browser interventions. The report can be saved, sent to the server, or or handled using arbitrary JavaScript. This feature is designed to give developers greater insight into the operation of their sites on real-world devices. Starting in Chrome 84, this API is exposed on workers. For more information on the API, see Know your code health with the ReportingObserver API.

Resize Observer Updates

The Resize Observer API was updated to conform to recent specs. ResizeObserverEntry has three new properties, contentBoxSize, borderBoxSize, and devicePixelContentBoxSize to provide more detailed information about the DOM feature being observed. This information is returned in an array of ResizeObserverSize objects, which are also new. For information about the API generally, including updates about the features, see ResizeObserver: it's like document.onresize for elements.

revert Keyword

The revert keyword resets the style of an element to the browser default.

Unprefixed Appearance CSS Property

An unprefixed version of -webkit-appearance is now available in CSS as appearance.

Unprefixed ruby-position CSS Property

The ruby-position property is now supported
in Chrome. This is an unprefixed version of -webkit-ruby-position, which controls the position of a ruby annotation. This property has three possible values: over, under, and inter-character, but Chrome has only implemented the first two. This change creates feature parity with Firefox.

Web Authenticator API: Cross-origin iframe Support

Adds support for web authentication calls from cross-origin iframes if enabled by a feature policy. This brings Chrome in line with the Web Authentication Level Two specification.

JavaScript

This version of Chrome incorporates version 8.4 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.

Private Methods and Accessors

Keeping state and behavior private to a class lets library authors present a clear, stable interface, while changing their code over time behind the scenes. Private class fields, which shipped in Chrome 74, added private fields for classes and instances. Now in Chrome 84, methods and properties can also be private. With this enhancement, any JavaScript class element can be private.

Weak references

The V8 engine now supports weak references to JavaScript objects, which help web developers define cleanup routines that don't keep the related objects alive but are (optionally) executed after the related object is garbage-collected. For more information, see Weak references and finalizers.

Deprecations, and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.

@import rules in CSSStyleSheet.replace() Removed

The original spec for constructable stylesheets allowed for calls to:

sheet.replace("@import('some.css');")

This use case is being removed. Calls to replace() now throw an exception if @import rules are found in the replaced content.

Remove TLS 1.0 and TLS 1.1

TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Both TLS 1.0 and 1.1 have a number of weaknesses.

• TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message.
• TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature. (Note: this is not the signature in the certificate.)
• TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS's CBC mode construction is flawed and is vulnerable to attacks.
• TLS 1.0's CBC ciphers additionally construct their initialization vectors incorrectly.
• TLS 1.0 is no longer PCI-DSS compliant.

Supporting TLS 1.2 is a prerequisite to avoiding the above problems. The TLS working group has deprecated TLS 1.0 and 1.1. Chrome has now also deprecated these protocols.

Why are you doing this?

Abusive notification prompts are one of the top user complaints we receive about Chrome. A large percentage of notification requests and notifications come from a small number of abusive sites. Protecting users from these sites improves user safety & privacy on the web, and makes for a better browsing experience. 

Only a small fraction of websites will be affected by this change but we expect the impact on notification volumes will be significant for some users.  

Notification UI changes for Chrome 84

Abusive notification protection in Chrome 84 will only affect new notification permission requests from abusive sites.  In the future, we may add protections for users who have already accepted notification permissions from abusive sites.   

Desktop UI for quiet notifications UI on abusive websites. The new UI discourages users from allowing notifications from these websites.  

Mobile UI for quiet notifications on abusive websites.  The new UI discourages users from allowing notifications from these websites.  

How do I know if my site has failed the abusive notification check?  

The Abusive Notifications Report in Search Console informs site owners of abusive notification experiences on their site. The first time a site is found to be in “Failing” status, Search Console will send an email to registered site owners and users in Search Console at least 30 calendar days prior to the start of enforcement. Websites will have the opportunity during this time period to address the issue and re-submit their website for another review.  

The Search Console help center has additional information on the Abusive Notifications Report and the abusive notification review process.

What should I do if my website failed the abusive notification review? 

The Search Console help center has a guide for how to fix abusive notifications and request a new review of your website.  

Posted by PJ McLachlan, Web Platform PM

In April, we temporarily rolled back the enforcement of SameSite cookie labeling to ensure stability for websites providing essential services in the critical initial stage of COVID-19 response. We indicated plans to resume the rollout over the summer.

Since April we have continued to monitor overall ecosystem readiness, and engage with websites and services to ensure they are prepared for the SameSite labeling policy. We are planning to resume our SameSite cookie enforcement coinciding with the stable release of Chrome 84 on July 14, with enforcement enabled for Chrome 80+.

As with the previous rollout, the enforcement will be gradual and we will keep you informed on timing and any possible changes on the SameSite Updates page on Chromium.org. Our overall guidance for developers hasn’t changed and you can find more information along with resources and channels to provide feedback in this previous Chromium post and on Web.dev.

Posted by Justin Schuh - Director, Chrome Engineering

Web Vitals is an initiative by Google to help business owners, marketers and developers alike identify opportunities to improve user experiences. These signals are guided by extensive work by many researchers in the fields of human–computer interaction (HCI) and user experience (UX). But figuring out the right metrics and thresholds is not as simple as picking up a research paper and finding the answer.

Journeys, not pages

Imagine you’re walking through an unfamiliar city to get to an important appointment. You walk through various streets and city centers on your way. But here and there, loose paving stones make you trip, there are slow automatic doors you have to wait for to open, and unexpected construction detours lead you astray. All of these events interrupt your progress, increase stress and distract you from reaching your destination.

People using the web are also on a journey, with each of their actions constituting one step in what would ideally be a continuous flow. And just like in the real world, they can be interrupted by delays, distracted from their tasks and led to make errors. These events, in turn, can lead to reduced satisfaction and abandonment of a site or the whole journey.

In both cases, removing interruptions and obstacles is the key to a smooth journey and a satisfied user.

So what trips users up on the web?

Interruptions due to waiting

The most common type of interruption web users experience is waiting for pages to load. For a developer, a page load is a discrete event and some delay might feel inevitable. However, a page load more often happens in the middle of a user's journey, as they learn about recent events in the news, research a new product or add items to a cart for purchase. So from the user's point of view, loading a particular page doesn't represent a natural break: they haven’t yet achieved their goal, which may make them less tolerant of delays.¹ This means pages need to load fast so the user's journey can flow smoothly.

How fast is fast enough? In a way, that’s the wrong question. There’s no single magic number and there's three main reasons why.

First, the answer depends on the outcome you consider, for instance abandonment, user satisfaction or task performance. Different studies focus on different outcomes and yield different results.

Second, the effect of delays varies hugely depending on a user's personality, past experience and the urgency of their task.² For example, if you were to plot how many users stayed on a site as a function of the delay they experienced, you would not see a clean step from 100% to 0% after X seconds. You would instead see a smooth distribution that might look like this:

So we must ask: which point on this curve do we aim for? In other words, how much do we invest in speed on the one hand, and how many of our users will we lose on the other?

Finally, the effect of delays varies depending on the context and situation. News sites, shopping sites and travel sites are often part of different kinds of user journeys, and the entire curve above might look different for each of them. Even within a context, site design and user behavior can change over time.

Although this is more difficult than we may have hoped, a distribution of outcomes at different levels of performance still contains useful hints. In particular, the distribution reveals how many users we may lose (or are losing currently) at a given level of performance. In addition, the steepness of the curve at different points can tell you how much return you’ll get for optimising speed by a particular amount. These are important factors in your tradeoff decision, since your time as a designer or engineer is also valuable.

So instead of looking for a single magic number, our goal is to find in the research useful ranges of values and reasonable guidelines. For example:

• One study found that delays decreased satisfaction and intention to return. On unfamiliar sites, 2 seconds of delay was enough to cause most of the drop – familiar sites bottomed out after longer delays. On unfamiliar sites, task performance also suffered, with most of the drop observed with delays of up to 4 seconds.³
• Another study involved navigating a nested menu on a web page. A range of delays, 3 seconds apart, was tested for loading each panel. Satisfaction dropped when increasing the delay from 0 to 3 seconds and again when going from 9 to 12 seconds. Intention to return also dropped with the 12-second delay. A 6-second delay was enough for some participants to remark on the site being slow.⁴
• One study found that mobile web users didn’t tend to keep their attention on the screen for more than 4–8 seconds at a time.⁵ This would mean that if they avert their attention before your page has loaded, the time they’re looking away further delays how soon they finally see the page. So a 5-second load time might turn into a 10-second effective delay.
• It’s been suggested that the speed of a system’s response should be comparable to the delays humans experience when they interact with one another. This has led to guidance that responses should take about 1–4 seconds.⁶

The empirical studies are drawn from data with high variability and gradual drop-offs rather than hard thresholds, and the others are based on predictions from theory. But collectively they suggest that it’s worth aiming to keep load times within a couple of seconds.

The Largest Contentful Paint (LCP) metric measures when a page-to-page navigation appears complete to a user. We recommend sites aim to keep LCP under 2.5 seconds for 75% of their page loads. This recommendation is further informed by Chrome analysis of the web today and aims to be feasible for enough sites to attain in practice. For more details of that analysis, see Defining the Core Web Vitals metric thresholds.

Interruptions and errors from instability

Most web pages need to load several elements, and often these load progressively. This can actually be a good thing: if some content appears as early as possible, it may allow a user to start making progress towards their goal without waiting for everything to load.

However, if the position of already-visible elements shifts as others load, this can negatively affect the user’s experience in two ways.

One is that if an element they’re looking at suddenly moves, it will take their eyes at least a couple hundred milliseconds to find its new position.⁷ If it scrolled out of view, it will take much longer. This type of interruption slows the user journey and can be very frustrating.

A more serious consequence is that unexpected layout shifts can lead to errors. If the user is trying to tap an element that then moves, they may end up tapping something else that moved into its original position. This is because the delay from perceiving the shift, deciding to abandon their action and then doing so can make it impossible for a human to respond appropriately. This could mean clicking a link or ad or "Buy Now" button unintentionally and significantly disrupting the user's intended journey.

Cumulative Layout Shift (CLS) measures how frequent and severe unexpected layout shifts are on a page. Fewer shifts mean less chance for interruption and errors. We recommend sites aim for a CLS of less than 0.1 for 75% of page loads.

Distraction and errors from low responsiveness

While page loads represent the larger transitions in a user’s journey – like entering a building – the small steps also matter.

When you’re walking, you don’t really want to be conscious of the mechanics of walking. Ideally, you actually forget that you’re walking and can focus on other things, like finding your way. But something like having a stone in your shoe will interfere with that concentration.

Likewise, you don’t want users’ experience to suffer from frictions in their moment-to-moment interactions with your site. Here are some research insights relevant to achieving this:

• One study found that a delay in visual feedback from touch screen buttons became perceivable when it was increased from 70ms to 100ms. When it was further increased from 100ms to 150ms, people also rated the quality of the buttons as significantly lower.⁸
• One experiment showed that in an animation, the illusion that one event caused another started breaking when there was a delay of about 100ms.⁹ It’s been suggested that similarly, the illusion of direct manipulation in user interfaces will break down with delays longer than this.¹⁰ (This guidance was apparently also informed by an earlier best-guess recommendation that actions should have a visible effect within 100–200ms.¹¹)

Just as for LCP, there’s no “magic number”, only markers representing distributions. Some individuals are much more sensitive than others,¹² and shorter delays may be noticed when haptic or auditory feedback is involved.¹³

Aside from changing how the UI feels, delaying something people expect to be near-instantaneous can lead them to make errors. They may repeat an action because they think it didn’t work, and the second action can have an undesirable effect. For example, they may click an “add to cart” button twice and not realise that they’re now buying two items.

The responsiveness related to these experiences is measured by First Input Delay (FID), and we recommend sites aim to keep FID under 100 milliseconds for 75% of page loads.

Impact

We analyzed millions of page impressions to understand how these metrics and thresholds affect users. We found that when a site meets the above thresholds, users are 24% less likely to abandon page loads (by leaving the page before any content has been painted).

We also looked specifically at news and shopping sites, sites whose businesses depend on traffic and task completion, and found similar numbers: 22% less abandonment for news sites and 24% less abandonment for shopping sites. There are few interventions that can show this level of improvement for online businesses, and results like these are part of the reason we and our ecosystem partners prioritize the Web Vitals metrics.

Providing a smooth journey for users is one of the most effective ways to grow online traffic and web-based businesses. We hope the Web Vitals metrics and thresholds will provide publishers, developers and business owners with clear and actionable ways to make their sites part of fast, interruption-free journeys for more users.

Amar Sagoo, Staff Interaction Designer
Annie Sullivan, Software Engineer
Vivek Sekhar, Product Manager

---

¹ Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
² Shneiderman, B. (1984). Response Time and Display Rate in Human Performance with Computers. ACM Computing Surveys (CSUR), 16(3), 265–285.
³ Galletta, D. F., Henry, R., McCoy, S. & Polak, P. (2004). Web Site Delays: How Tolerant are Users? Journal of the Association for Information Systems, 5(1), 1.
⁴ Hoxmeier, J. A. & DiCesare, C. (2000). System Response Time and User Satisfaction: An Experimental Study of Browser-based Applications. AMCIS 2000 Proceedings, 347.
⁵ Oulasvirta, A., Tamminen, S., Roto, V. & Kuorelahti, J. (2005). Interaction in 4-Second Bursts: The Fragmented Nature of Attentional Resources in Mobile HCI. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 919–928).
⁶ Card, S. K., Robertson, G. G., & Mackinlay, J. D. (1991). The information visualizer, an information workspace. In Proceedings of the SIGCHI Conference on Human factors in computing systems (pp. 181-186).
Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
⁷ Purves D., Augustine G. J., Fitzpatrick D., et al. (2001). Types of Eye Movements and Their Functions. Neuroscience (2nd edition).
⁸ Kaaresoja, T., Brewster, S., & Lantz, V. (2014). Towards the Temporally Perfect Virtual Button: Touch-Feedback Simultaneity and Perceived Quality in Mobile Touchscreen Press Interactions. ACM Transactions on Applied Perception (TAP), 11(2), 1–25.
⁹ Card, S. K. (Ed.). (2018). The psychology of human-computer interaction. Crc Press.
¹⁰ Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
¹¹ Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
¹² Jota, R., Ng, A., Dietz, P., & Wigdor, D. (2013, April). How fast is fast enough? a study of the effects of latency in direct-touch pointing tasks. In Proceedings of the sigchi conference on human factors in computing systems (pp. 2291-2300).
¹³ Kaaresoja, T., Brewster, S., & Lantz, V. (2014). Towards the Temporally Perfect Virtual Button: Touch-Feedback Simultaneity and Perceived Quality in Mobile Touchscreen Press Interactions. ACM Transactions on Applied Perception (TAP), 11(2), 1–25.

With Chrome 83, we’ve started rolling out Secure DNS, a feature built on top of a secure DNS protocol called DNS-over-HTTPS, which is designed to improve your safety and privacy while browsing the web. More concretely, Chrome will automatically switch to DNS-over-HTTPS if your current DNS provider supports it, and provide manual configuration options for users who wish to use a specific provider. DNS-over-HTTPS introduces a significant change to the Domain Name System (DNS), a system designed more than 35 years ago that is central to how the web works even to this day. It’s the sort of change that requires careful planning and collaboration, which explains why it took us a little more than 2 years, gathering test data, listening to feedback, and addressing some misconceptions, to arrive at a design that put our users first with reasonable defaults and accessible controls.

Unencrypted DNS

When you want to access your favorite website, your browser first needs to determine which server is hosting it, a step known as “DNS lookup”. When DNS was first introduced, the internet was in its infancy, and the web did not yet exist. There was no e-commerce, no online banks, and many people did not yet see a strong need for encryption on the web. It took until 1994 for encryption to take-off with the introduction of the HTTPS protocol. Nowadays, the HTTPS protocol is almost ubiquitous and provides strong security and privacy guarantees. It helps you browse or transact on the web without fear of having your credit card or personal information stolen by other internet users, even when using a public WiFi connection. Unfortunately, DNS, on the other hand, until recently has remained unencrypted.

Benefits of DNS-over-HTTPS

Chrome’s Secure DNS feature uses DNS-over-HTTPS to encrypt the DNS communication, thereby helping prevent attackers from observing what sites you visit or sending you to phishing websites. As the name suggests, Chrome communicates with the DNS service provider over the HTTPS protocol, the same protocol used for communicating with websites in a safe and secure manner. HTTPS is particularly appealing because it provides the following protections:

Chrome is developed to be fast and responsive without harmful or annoying experiences. Recently, following the Better Ads Standards, we have taken steps to address ads that most people find unacceptable. Prior to that, we also launched a set of protections against abusive experiences in Chrome.