Since the beginning of Chrome, benchmarks have been a key way by which we drive performance optimizations that benefit users. The most relevant web benchmarks today are Speedometer, MotionMark, and Jetstream. Over the last year Chrome has invested in optimizing against these specific benchmarks and has just achieved our highest scores across all three. These gains were achieved through a combination of large projects and small improvements. In today’s The Fast and the Curious post, we want to share just some of the ways we drove these improvements in Chrome.
We’re bringing a new mid-tier compiler to Chrome. Maglev is a just-in-time compiler that can quickly generate performant machine code for all relevant functions within the first one-hundredth of a second. It reduces overall CPU time to compile code while also saving battery life. Our measurements show Maglev has provided a 7.5 percent improvement on Jetstream and a 5 percent improvement in Speedometer. Maglev will start rolling out in Chrome version 114, which begins release on June 5.
Speedometer measures the responsiveness of websites by putting various JavaScript UI frameworks through their paces. Just over a year ago we shared details about how we increased our score from 100 to over 300 from Chrome version 40 to version 101. Since then, across 13 Chrome releases, we’ve achieved our new highest Speedometer score of 491. In addition to Maglev, the V8 team has achieved this score through both small adjustments, such as optimized function calls, and major, multi-quarter projects.
MotionMark is designed to test how much browser graphics systems can render at high frame rates. Chrome’s graphics and rendering teams have tracked over 20 optimizations since the start of the year, and more than half are available today. Together, these optimizations have almost tripled performance. Some highlights include improvements to Canvas performance, profile-guided optimization, GPU task scheduling, and layer compositing. We also created a novel algorithm for dynamic multisample anti-aliasing and out-of-process 2D canvas rasterization for improved parallelism.
JetStream is a JavaScript and WebAssembly benchmark suite focused on advanced web applications. Many of the updates that we made for Speedometer also drove significant improvements on Jetstream as we optimized the V8 engine. In addition to these enhancements, Maglev drove the biggest gains in this benchmark.
Looking ahead
Because we’re optimizing against these benchmarks, it’s essential that these improvements translate to real user benefits, which is why we’re investing, along with other browsers, in creating the next generation of benchmarks. This has been an ongoing collaboration, and we’re excited to turn our efforts toward this new target in the coming year.
We hope you all enjoy a faster Chrome!
From the very beginning, we built Chrome to be the fastest browser possible. The faster Chrome is, the faster you find the information you want or finish the task you need to do. With M85, users will find a noticeably faster Chrome, thanks to our two latest improvements: Profile Guided Optimization, which delivers up to 10% faster page loads; and Tab Throttling, which helps reduce the impact of idle background tabs, coming to the Beta channel.
PGO was initially introduced in M53 for Chrome on Windows using Microsoft Visual C++ (MSVC), our previous build environment. In M85, we are rolling out PGO on Mac and Windows using Clang. Our testing consistently shows pages loading up to 10% faster at the median, and even greater speed improvements when your CPU is tasked with running many tabs or programs.
Platform
Browser Responsiveness*
First Contentful Paint**
Speedometer 2.0
Mac
3.9% faster
2.3% faster
7.7% faster
Windows
7.3% faster
3.5% faster
11.4% faster
Chrome's performance - speed and usage of resources like power, memory, or CPU - has always been top of mind. We have a dedicated engineering team that has been consistently (and quietly) making improvements so Chrome runs faster and smoother on all devices, operating systems, and internet conditions. No matter if you are a heavy tab user on your Windows laptop, or need a lightweight app experience on your Android phone, we are working hard to use your device resources most efficiently.
Posted by Max Christoff, Engineering Director, Chrome
*How fast your browser responds to user input (real world data anonymously aggregated from Chrome pre-stable channels)
** The time it takes the first text or image to be displayed upon loading a page (real world data anonymously aggregated from Chrome pre-stable channels)
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.
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?
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.1 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.2 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:
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.
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.7 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.
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:
Just as for LCP, there’s no “magic number”, only markers representing distributions. Some individuals are much more sensitive than others,12 and shorter delays may be noticed when haptic or auditory feedback is involved.13
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.
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
