Michal Mocny on web.dev

Using the Web Vitals extension to debug Core Web Vitals issues

2023-05-04T00:00:00Z

The Web Vitals extension provides easy access to Core Web Vitals diagnostic information to help developers measure, and address Core Web Vitals issues. It supplements the other tools provided by the Chrome team to aid developers in improving the experiences on their websites.

We have updated the extension to provide additional debug information to developers to make it easier to understand and address their performance problems.

Showing debug information in the console #

The Web Vitals extension has had a "Console Logging" debug option for some time now. It can be enabled in the Options screen:

Prior to the this last upgrade, this logged the outputs from the web-vitals library (that underpins the extension) in a JSON object:

This object could then be expanded to get the full details, and elements such as the LCP image, could be hovered over to highlight them in the main panel:

This was helpful, but the output format was not particularly user friendly, and we thought we could provide a better developer experience. So we have improved the extension to make the most important information more visible—while still including the full object for those wanting more details.

New debug information for each metric #

With the new release, we have added new debug information in a more readable format to help you find and address issues. Different information is provided for each of the metrics, as each one is different.

LCP debug information #

For Largest Contentful Paint (LCP), we show both the element, and the breakdown of the 4 phases detailed in our Optimize LCP guide:

The LCP time (2,876 milliseconds—or about 2.9 seconds) is highlighted in amber as it is in the "Needs Improvement" category.

In this example, we see the Resource load time is the longest time, so to improve your LCP time you would look to optimize that - perhaps by avoiding hosting them on a separate domain, or by using smaller images or more efficient formats. In this case it's due to being artificially slowed down to demonstrate the output—web.dev is a fast site 😀

The element can also be hovered over to highlight the image:

Right clicking on the element also allows you to reveal it in the elements panel.

Here the LCP element is an image, and hovering over that in the console on the right, also highlights that element on the site on the left.

CLS debug information #

Shifts contributing to Cumulative Layout Shift (CLS) are now also listed, and can be hovered over to highlight the relevant element:

The above screenshot shows 2 shifts, the first made up of two elements (when the banner image is loaded and the content beneath it is shifted downloaded), and the second of 4 elements (when the dynamic ad is loaded and most of the page is shifted downwards).

The h2 element is being hovered over in this screenshot in the console on the right, and you can see this highlights the element on the site on the left.

FID debug information #

For First Input Delay (FID) we show the affected element (which again, can be hovered over to highlight it on the page) and the interaction type, along with the full JSON object as usual:

INP debug information #

For Interaction to Next Paint (INP), we have added two new logs:

INP - the longest interaction
Interactions - all interactions

INP metric #

First up, we highlight the INP metric when it changes:

Similar to LCP, the extension breaks down the INP time to show three phases:

Input delay
Processing time
Presentation delay

This helps you identify if the event was slow due to being held up by other events (input delay), as the event handler itself was slow due to your code (processing time), if the post-processing render delay was the reason (presentation delay), or a combination of two or more of these.

Interactions #

INP can be slow due to previous interactions blocking the main thread, and thus causing a high input delay. For this reason, we list all interactions in a similar format to the INP logging:

This allows you to "live trace" a website by interacting with it and seeing in the console which interactions, in which combinations, are likely to cause an INP problem.

This also allows you to identify multiple slow interactions, rather than just the largest INP interaction to help you avoid the feeling of chasing your tail when improving your responsiveness.

Filtering the console logs #

All this extra information, while useful, can be distracting if you are doing other development unrelated to Core Web Vitals, or are only interested in one particular Core Web Vital at that time.

You can use the Console filtering options in DevTools to filter out some or all of the messages:

To remove all the extension messages, you can either turn this off in the options or use the -Extension filter.
To look at just LCP you can use the Web Vitals Extension LCP filter.
To look at just INP and interactions you can use the Web Vitals Extension -LCP -CLS -FID filter.

We're trying to keep the number of options for this extension down, but do let us know by raising a GitHub issue if DevTools filtering is not sufficient and you would prefer options here.

Conclusion #

We hope you find the new debug options in the latest version of the extension useful and that they make it easier to identify and resolve Core Web Vitals issues, improving the user experiences on your website.

Do remember that your experiences, on your developer computer, may not be representative of what your real users are experiencing. Check out our previous blog post on how you can view the CrUX field data for your site in the extension to get a sense of how aligned your experiences are with your users.

We would be grateful to hear any feedback on these improvements, or any other suggestions on our GitHub issues tracker.

Acknowledgements #

Hero image by Farzad on Unsplash

Towards an animation smoothness metric

2021-11-03T00:00:00Z

You've probably experienced pages that "stutter" or "freeze" during scrolling or animations. We like to say that these experiences are not smooth. To address these types of issues, the Chrome team has been working on adding more support to our lab tooling for animation detection, as well as making steady improvements to the rendering pipeline diagnostics within Chromium.

We'd like to share some recent progress, offer concrete tooling guidance, and discuss ideas for future animation smoothness metrics. As always, we would love to hear your feedback.

This post will cover three main topics:

A quick look at animations and animation frames.
Our current thoughts on measuring overall animation smoothness.
A few practical suggestions for you to leverage in lab tooling today.

What are animations? #

Animations bring content to life! By making content move, especially in response to user interactions, animations can make an experience feel more natural, understandable, and fun.

But poorly implemented animations, or just adding too many animations, can degrade the experience and make it decidedly not fun at all. We've probably all interacted with an interface which just added too many "helpful" transition effects, which actually become hostile to experience when they perform poorly. Some users therefore actually might prefer reduced motion, a user preference that you should honor.

How do animations work? #

As a quick recap, the rendering pipeline consists of a few, sequential stages:

Style: Calculate the styles that apply to the elements.
Layout: Generate the geometry and position for each element.
Paint: Fill out the pixels for each element into layers.
Composite: Draw the layers to the screen.

While there are many ways to define animations, they all fundamentally work via one of the following:

Adjusting layout properties.
Adjusting paint properties.
Adjusting composite properties.

Because these stages are sequential, it is important to define animations in terms of properties that are further down the pipeline. The earlier the update happens in the process, the greater are the costs and it's less likely to be smooth. (See Rendering performance for more details.)

While it can be convenient to animate layout properties, there are costs to doing so, even if those costs aren't immediately apparent. Animations should be defined in terms of composite property changes wherever possible.

Defining declarative CSS animations or using Web Animations, and ensuring you animate composite properties, is a great first step to ensuring smooth and efficient animations. But still, this alone does not guarantee smoothness because even efficient web animations have performance limits. That's why it is always important to measure!

What are animation frames? #

Updates to the visual representation of a page take time to appear. A visual change will lead to a new animation frame, which is eventually rendered on the user's display.

Displays update on some interval, so visual updates are batched. Many displays update on a fixed interval of time, such as 60 times a second (that is 60 Hz). Some more modern displays can offer higher refresh rates (90–120 Hz are becoming common). Often these displays can actively adapt between refresh rates as needed, or even offer fully variable frame rates.

The goal for any application, like a game or a browser, is to process all these batched visual updates and produce a visually complete animation frame within the deadline, every time. Note that this goal is entirely distinct from other important browser tasks such as loading content from the network quickly or executing JavaScript tasks efficiently.

At some point, it can become too difficult to complete all visual updates within the allotted deadline assigned by the display. When this happens, the browser drops a frame. Your screen doesn't go black, it just repeats itself. You see the same visual update for a bit longer—the same animation frame that was presented at the previous frame opportunity.

This actually happens often! It is not necessarily even perceptible, especially for static or document-like content, which is common on the web platform in particular. Dropped frames only become apparent when there are important visual updates, such as animations, for which we need a steady stream of animation updates to show smooth motion.

What impacts animation frames? #

Web developers can greatly impact the ability of a browser to quickly and efficiently render and present visual updates!

Some examples:

Using content that is too large or resource-intensive to decode quickly on the target device.
Using too many layers requiring too much GPU memory.
Defining overly complex CSS styles or web animations.
Using design anti-patterns that disable fast rendering optimizations.
Too much JS work on the main thread, leading to long tasks that block visual updates.

But how can you know when an animation frame has missed its deadline and caused a dropped frame?

One possible method is using requestAnimationFrame() polling, however it has several downsides. requestAnimationFrame(), or "rAF", tells the browser that you wish to perform an animation and asks for an opportunity to do so before the next paint stage of the rendering pipeline. If your callback function isn't called at the time you expect it, that means a paint wasn't executed, and one or more frames were skipped. By polling and counting how often rAF is called, you can compute a sort of "frames per second" (FPS) metric.

let frameTimes = [];
function pollFramesPerSecond(now) {
  frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
  requestAnimationFrame(pollFramesPerSecond);
  console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);

Using requestAnimationFrame() polling is not a good idea for several reasons:

Every script has to set up its own polling loop.
It can block the critical path.
Even if the rAF polling is fast, it can prevent requestIdleCallback() from being able to schedule long idle blocks when used continuously (blocks that exceed a single frame).
Similarly, lack of long idle blocks prevents the browser from scheduling other long-running tasks (such as longer garbage collection and other background or speculative work).
If polling is toggled on and off, then you'll miss cases where frame budget has been exceeded.
Polling will report false-positives in cases where the browser is using variable update frequency (for example, due to power or visibility status).
And most importantly, it doesn't actually capture all types of animation updates!

Too much work on the main thread can impact the ability to see animation frames. Check out the Jank Sample to see how a rAF-driven animation, once there is too much work on the main thread (such as layout), will lead to dropped frames and fewer rAF callbacks, and lower FPS.

When the main thread becomes bogged down, visual updates begin to stutter. That's jank!

Many measurement tools have focused extensively on the ability for the main thread to yield in a timely manner, and for animation frames to run smoothly. But this is not the whole story! Consider the following example:

The video above shows a page that periodically injects long tasks onto the main thread. These long tasks completely ruin the ability of the page to provide certain types of visual updates, and you can see in the top-left corner a corresponding drop of requestAnimationFrame() reported FPS to 0.

And yet, despite these long tasks, the page continues to scroll smoothly. This is because on modern browsers, scrolling is often threaded, driven entirely by the compositor.

This is an example that simultaneously contains many dropped frames on the main thread, yet still has many successfully-delivered frames of scrolling on the compositor thread. Once the long task is complete, the main thread paint update has no visual change to offer anyway. rAF polling suggested a frame drop to 0, but visually, a user wouldn't be able to notice a difference!

For animation frames, the story is not that simple.

Animation frames: Updates that matter #

The above example showcases that there is more to the story than just requestAnimationFrame().

So when do animation updates and animation frames matter? Here are some criteria we're thinking about and would love to get feedback on:

Main and compositor thread updates
Missing paint updates
Detecting animations
Quality versus quantity

Main and compositor thread updates #

Animation frame updates are not boolean. It is not the case that frames may only be fully dropped or fully presented. There are many reasons why an animation frame may be partially presented. In other words, it can simultaneously have some stale content while also having some new visual updates which are presented.

The most common example of this is when the browser is unable to produce a new main thread update within frame deadline but does have a new compositor thread update (such as the threaded scrolling example from earlier).

One important reason why using declarative animations to animate composite properties is recommended is that doing so enables an animation to be driven entirely by the compositor thread even when the main thread is busy. These types of animations can continue to produce visual updates efficiently and in parallel.

On the other hand, there may be cases where a main thread update finally becomes available for presentation, but only after missing several frame deadlines. Here the browser will have some new update, but it may not be the very latest.

Broadly speaking, we consider frames that contain some new visual updates, without all new visual updates, as a partial frame. Partial frames are fairly common. Ideally, partial updates would at least include the most important visual updates, like animations, but that can only happen if animations are driven by the compositor thread.

Missing paint updates #

Another type of partial update is when media like images have not finished decoding and rasterizing in time for frame presentation.

Or, even if a page is perfectly static, browsers may still fall behind rendering visual updates during rapid scrolling. That is because the pixel renditions of content beyond the visible viewport may be discarded to save GPU memory. It takes time to render pixels, and it may take longer than a single frame to render everything after a large scroll, like a finger fling. This is commonly known as checkerboarding.

With each frame rendering opportunity, it's possible to track how much of the latest visual updates actually got to the screen. Measuring the ability to do so over many frames (or time) is broadly known as frame throughput.

If the GPU is really bogged down, the browser (or platform) may even begin to throttle the rate at which it attempts visual updates and thus decreases effective frame rates. While technically that can reduce the number of dropped frame updates, visually it will still appear as a lower frame throughput.

Yet, not all types of low frame throughput are bad. If the page is mostly idle and there are no active animations, a low frame rate is just as visually appealing as a high frame rate (and, it can save battery!).

So when does frame throughput matter?

Detecting animations #

High frame throughput matters especially during periods with important animations. Different animation types will depend on visual updates from a specific thread (main, compositor, or a worker), so its visual update is dependent on that thread providing its update within the deadline. We say that a given thread affects smoothness whenever there is an active animation that depends on that thread update.

Some types of animations are easier to define and detect than others. Declarative animations, or user-input-driven animations, are clearer to define than JavaScript-driven animations implemented as periodic updates to animatable style properties.

Even with requestAnimationFrame() you cannot always assume that every rAF call is necessarily producing a visual update or animation. For example, using rAF polling just to track frame rate (as shown above) should not itself affect smoothness measurements since there is no visual update.

Quality versus quantity #

Finally, detecting animations and animation frame updates is still only part of the story because it only captures the quantity of animation updates, not the quality.

For example, you may see a steady framerate of of 60 fps while watching a video. Technically, this is perfectly smooth, but the video itself may have a low bit rate, or issues with network buffering. This isn't captured by animation smoothness metrics directly, yet may still be jarring to the user.

Or, a game which leverages <canvas> (perhaps even using techniques like offscreen canvas to ensure a steady frame rate) may technically be perfectly smooth in terms of animation frames, all while failing to load high quality game assets into the scene or exhibiting rendering artifacts.

And of course, a site can just have some really bad animations 🙂

I mean, I guess they were pretty cool for their time!

States of a single animation frame #

Because frames may be partially presented, or dropped frames may happen in ways that do not affect smoothness, we have begun to think of each frame as having a completeness or smoothness score.

Here is the spectrum of ways in which we interpret the state of a single animation frame, ordered from best to worst case:

No Update Desired	Idle time, repeat of the previous frame.
Fully presented	The main thread update was either committed within deadline, or no main thread update was desired.
Partially presented	Compositor only; the delayed main thread update had no visual change.
Partially presented	Compositor only; the main thread had a visual update, but that update did not include an animation that affects smoothness.
Partially presented	Compositor only; the main thread had a visual update that affects smoothness, but a previously stale frame arrived and was used instead.
Partially presented	Compositor only; without the desired main update, and the compositor update has an animation that affects smoothness.
Partially presented	Compositor only but the compositor update does not have an animation that affects smoothness.
Dropped frame	No update. There was no compositor update desired, and main was delayed.
Dropped frame	A compositor update was desired, but it was delayed.
Stale frame	An update was desired, it was produced by the renderer, but the GPU still did not present it before the vsync deadline.

It's possible to turn these states into somewhat of a score. And perhaps one way to interpret this score is to consider it a probability of being observable by the user. A single dropped frame may not be very observable, but a sequence of many dropped frames affecting smoothness in a row sure is!

Putting it all together: A Percent Dropped Frames metric #

While it can sometimes be necessary to dive deep into the state of each animation frame, it's also useful to just assign a quick "at a glance" score for an experience.

Because frames may be partially presented, and because even fully skipped frame updates may not actually affect smoothness, we want to focus less on just counting frames, and more on the extent to which the browser is unable to provide visually complete updates when it mattered.

The mental model should move from:

Frames Per Second, to
Detecting missing and important animation updates, to
Percentage Dropped over a given time period.

What matters is: the proportion of time waiting for important updates. We think this matches the natural way users experience the smoothness of web content in practice. So far, we have been using the following as an initial set of metrics:

Average Percent Dropped: for all non-idle animation frames throughout the whole timeline
Worst Case of Percent Dropped Frames: as measured over 1 second sliding windows of time.
95th percentile of Percent Dropped Frames: as measured over 1 second sliding windows of time.

You can find these scores in some Chrome developer tools today. While these metrics focus only on overall frame throughput, we are also evaluating other factors, such as frame latency.

Try it yourself in developer tooling! #

Performance HUD #

Chromium has a neat Performance HUD hidden behind a flag (chrome://flags/#show-performance-metrics-hud). In it, you can find live scores for things like Core Web Vitals and also a few experimental definitions for animation smoothness based on Percent Dropped Frames over time.

Frame Rendering Stats #

Enable "Frame Rendering Stats" in DevTools via Rendering settings to see a live view of new animation frames, which are color-coded to differentiate partial updates from fully-dropped frame updates. The reported fps is for fully-presented frames only.

Frame Viewer in DevTools performance profile recordings #

The DevTools Performance panel has long had a Frames viewer. However, it had grown a bit out of sync with how the modern rendering pipeline actually works. There has been plenty of recent improvement, even in the latest Chrome Canary, which we think will greatly ease debugging animation issues.

Today you will find that frames in the frames viewer are better aligned with vsync boundaries, and color-coded based on status. There is still not full visualization for all the nuances outlined above, but we're planning to add more in the near future.

Chrome tracing #

Finally, with Chrome Tracing, the tool of choice for diving deep into details, you can record a "Web content rendering" trace via the new Perfetto UI (or about:tracing), and dig deep into Chrome's graphics pipeline. It can be a daunting task, but there are a few things recently added to Chromium to make it easier. You can get an overview of what is available in the Life of a Frame document.

Through trace events you can definitively determine:

Which animations are running (using events named TrackerValidation).
Getting the exact timeline of animation frames (using events named PipelineReporter).
For janky animation updates, figure out exactly what is blocking your animation from running faster (using the event breakdowns within PipelineReporter events).
For input-driven animations, see how long it takes to get a visual update (using events named EventLatency).

What's next #

The Web Vitals initiative aims to provide metric and guidance for building great user experiences on the web. Lab-based metrics like Total Blocking Time (TBT) and Time to Interactive (TTI) are vital for catching and diagnosing potential interactivity issues. We are planning to design a similar lab-based metric for animation smoothness.

We'll keep you posted as we continue to work through ideas for designing a comprehensive metric based on individual animation frame data.

In the future, we'd also like to design APIs that make it possible to measure animation smoothness performantly for real users in the field as well as in the lab. Stay tuned for updates there as well!

Feedback #

We're excited about all the recent improvements and developer tools that have shipped in Chrome to measure animation smoothness. Please try these tools out, benchmark your animations, and let us know where it leads!

You can send your comments to the web-vitals-feedback Google group with "[Smoothness Metrics]" in the subject line. We're really looking forward to hearing what you think!

Feedback wanted: The road to a better layout shift metric for long-lived pages

2021-01-25T00:00:00Z

Cumulative Layout Shift (CLS) is a metric that measures the visual stability of a web page. The metric is called cumulative layout shift because the score of every individual shift is summed throughout the lifespan of the page.

While all layout shifts are poor user experiences, they do add up more on pages that are open longer. That's why the Chrome Speed Metrics Team set out to improve the CLS metric to be more neutral to the time spent on a page.

It's important that the metric focuses on user experience through the full page lifetime, as we've found that users often have negative experiences after load, while scrolling or navigating through pages. But we've heard concerns about how this impacts long-lived pages—pages which the user generally has open for a long time. There are several different types of pages which tend to stay open longer; some of the most common are social media apps with infinite scroll and single-page applications.

An internal analysis of long-lived pages with high CLS scores found that most problems were caused by the following patterns:

Infinite scrollers shifting content as the user scrolls.
Input handlers taking longer than 500 ms to update the UI in response to a user interaction, without any kind of placeholder or skeleton pattern.

While we encourage developers to improve those user experiences, we're also working towards improving the metric and looking for feedback on possible approaches.

How would we decide if a new metric is better? #

Before diving into metric design, we wanted to ensure that we evaluated our ideas on a wide variety of real-world web pages and use cases. To start, we designed a small user study.

First, we recorded videos and Chrome traces of 34 user journeys through various websites. In selecting the user journeys, we aimed for a few things:

A variety of different types of sites, such as news and shopping sites.
A variety of user journeys, such as initial page load, scrolling, single-page app navigations, and user interactions.
A variety of both number and intensity of individual layout shifts on the sites.
Few negative experiences on the sites apart from layout shifts.

We asked 41 of our colleagues to watch two videos at a time, rating which of the pair was better in terms of layout shift. From these ratings, we created an idealized ranking order of the sites. The results of the user ranking confirmed our suspicions that our colleagues, like most users, are really frustrated by layout shifts after load, especially during scrolling and single-page app navigations. We saw that some sites have much better user experiences during these activities than others.

Since we recorded Chrome traces along with the videos, we had all the details of the individual layout shifts in each user journey. We used those to compute metric values for each idea for each user journey. This allowed us to see how each metric variant ranked the user journeys, and how different each was from the ideal ranking.

What metric ideas did we test? #

Windowing strategies #

Often pages have multiple layout shifts bunched closely together, because elements can shift multiple times as new content comes in piece by piece. This prompted us to try out techniques for grouping shifts together. To accomplish that, we looked at three windowing approaches:

Tumbling windows
Sliding windows
Session windows

In each of these examples, the page has layout shifts of varying severity over time. Each blue bar represents a single layout shift, and the length represents the score of that shift. The images illustrate the ways different windowing strategies group the layout shifts over time.

Tumbling windows #

Example of a tumbling window.

The simplest approach is just to break the page into windows of equal-sized chunks. These are called tumbling windows. You'll notice above that the fourth bar really looks like it should be grouped into the second tumbling window, but because the windows are all a fixed size it is in the first window instead. If there are slight differences in timing of loads or user interactions on the page, the same layout shifts might fall on different sides of the tumbling window boundaries.

Sliding windows #

Example of a sliding window.

An approach that lets us see more possible groupings of the same length is to continuously update the potential window over time. The image above shows one sliding window at a time, but we could look at all possible sliding windows or a subset of them to create a metric.

Session windows #

Example of a session window.

If we wanted to focus on identifying areas of the page with bursts of layout shifts, we could start each window at a shift, and keep growing it until we encountered a gap of a given size between layout shifts. This approach groups the layout shifts together, and ignores most of the non-shifting user experience. One potential problem is that if there are no gaps in the layout shifts, a metric based on session windows could grow unbounded just like the current CLS metric. So we tried this out with a maximum window size as well.

Window sizes #

The metric might give very different results depending on how big the windows actually are, so we tried multiple different window sizes:

Each shift as its own window (no windows)
100 ms
300 ms
1 second
5 seconds

Summarization #

We tried out many ways to summarize the different windows.

Percentiles #

We looked at the maximum window value, as well as the 95th percentile, 75th percentile, and median.

Average #

We looked at the mean window value.

Budgets #

We wondered if maybe there was some minimum layout shift score that users wouldn't notice, and we could just count layout shifts over that "budget" in the score. So for various potential "budget" values, we looked at the percentage of shifts over budget, and the total shift score over budget.

Other strategies #

We also looked at many strategies that didn't involve windows, like the total layout shift divided by time on page, and the average of the worst N individual shifts.

The initial results #

Overall, we tested 145 different metric definitions based on permutations of the above ideas. For each metric, we ranked all the user journeys by their score on the metric, and then ranked the metrics by how close they were to the ideal ranking.

To get a baseline, we also ranked all the sites by their current CLS score. CLS placed 32nd, tied with 13 other strategies, so it was better than most permutations of the strategies above. To ensure the results were meaningful, we also added in three random orderings. As expected, the random orderings did worse than every strategy tested.

To understand if we might be overfitting for the data set, after our analysis we recorded some new layout shift videos and traces, manually ranked those, and saw that the metric rankings were very similar for the new data set and the original one.

A few different strategies stood out in the rankings.

Best strategies #

When we ranked the strategies, we found that three types of strategies topped the list. Each had roughly the same performance, so we plan to move forward with a deeper analysis on all three. We'd also like to hear developer feedback to understand if there are factors outside of user experience we should be considering when deciding between them. (See below for how to give feedback.)

High percentiles of long windows #

A few windowing strategies worked well with long window sizes:

1 second sliding windows
Session windows capped at 5 seconds with 1 second gap
Session windows uncapped with 1 second gap

These all ranked really well at both the 95th percentile and the maximum.

But for such large window sizes, we were concerned about using the 95th percentile—often we were looking at only 4-6 windows, and taking the 95th percentile of that is a lot of interpolation. It's unclear what the interpolation is doing in terms of the metric value. The maximum value is a lot clearer, so we decided to move forward with checking the maximum.

Average of session windows with long gaps #

Averaging the scores of all uncapped session windows with 5 second gaps between them performed really well. This strategy has a few interesting characteristics:

If the page doesn't have gaps between layout shifts, it ends up being one long session window with the exact same score as the current CLS.
This metric didn't take idle time into account directly; it only looked at the shifts that happened on the page, and not at points in time when the page was not shifting.

High percentiles of short windows #

The maximum 300 ms sliding window ranked very highly, as well as the 95th percentile. For the shorter window size, there is less percentile interpolation than larger window sizes, but we were also concerned about "repeat" sliding windows—if a set of layout shifts occurs over two frames, there are multiple 300 ms windows that include them. Taking the maximum is much clearer and simpler than taking the 95th percentile one. So again we decided to move forward with checking the maximum.

Strategies that didn't work out #

Strategies that tried to look at the "average" experience of time spent both without layout shifts and with layout shifts did very poorly. None of the median or 75th percentile summaries of any windowing strategy ranked the sites well. Neither did the sum of layout shifts over time.

We evaluated a number of different "budgets" for acceptable layout shifts:

Percent of layout shifts above some budget. For various budgets, these all ranked quite poorly.
Average layout shift above some excess. Most variations on this strategy did poorly, but average excess over a long session with a large gap did almost as well as the average of session windows with long gaps. We decided to move forward with only the latter because it is simpler.

Next steps #

Larger-scale analysis #

We've implemented the top strategies listed above in Chrome, so that we can get data on real-world usage for a much larger set of websites. We plan to use a similar approach of ranking sites based on their metric scores to do the larger-scale analysis:

Rank all the sites by CLS, and by each new metric candidate.
- Which sites are ranked most differently by CLS and each candidate? Do we find anything unexpected when we look at these sites?
- What are the largest differences between the new metric candidates? Do any of the differences stand out as advantages or disadvantages of a specific candidate?
Repeat the above analysis, but bucketing by time spent on each page load. Do we see an expected improvement for long-lived page loads with acceptable layout shift? Do we see any unexpected results for short-lived pages?

Feedback on our approach #

We'd love to get feedback from web developers on these approaches. Some things to keep in mind while considering the new approaches:

What's not changing #

We do want to clarify that a lot of things will not be changing with a new approach:

None of our metric ideas change the way layout shift scores for individual frames are calculated, only the way we summarize multiple frames. This means that the JavaScript API for layout shifts will stay the same, and the underlying events in Chrome traces that developer tools use will also stay the same, so layout shift rects in tools like WebPageTest and Chrome DevTools will continue to work the same way.
We'll continue to work hard on making the metrics easy for developers to adopt, including them in the web-vitals library, documenting on web.dev, and reporting them in our developer tooling like Lighthouse.

Trade-offs between metrics #

One of the top strategies summarizes the layout shift windows as an average, and the rest report the maximum window. For pages which are open a very long time, the average will likely report a more representative value, but in general it will likely be easier for developers to act on a single window—they can log when it occurred, the elements that shifted, and so on. We'd love feedback on which is more important to developers.

Do you find sliding or session windows easier to understand? Are the differences important to you?

How to give feedback #

You can try out the new layout shift metrics on any site using our example JavaScript implementations or our fork of the Core Web Vitals extension.

Please email feedback to our web-vitals-feedback Google group, with "[Layout Shift Metrics]" in the subject line. We're really looking forward to hearing what you think!