Rethinking CLS for Pages Users Keep Open

Cumulative Layout Shift (CLS) sums every unexpected movement of page content over a page's entire lifetime. That design works reasonably well for typical browsing sessions, but it penalizes pages that stay open for a long time, even when their layout is perfectly stable for most of that period.

The Chrome Speed Metrics Team has been investigating metric changes that remain fair to long-lived pages while preserving the signal that matters. Their work is driven by user studies and trace data, and they are inviting developer feedback on candidate designs.

What User Testing Revealed

To validate any new metric, the team first needed a ground truth for what "good" and "bad" visual stability actually look like. They recorded videos and Chrome traces of 34 user journeys through a diverse set of sites, covering initial loads, scrolling, single-page app navigations, and user interactions—with varying numbers and intensities of layout shifts.

They then asked 41 colleagues to pairwise rank videos of these journeys by their layout shift experience, which produced an idealized ordering. Comparing this with the trace data yielded two notable findings: users are particularly bothered by shifts that happen after page load, notably during scrolling and in-page navigations, and the current CLS metric only ranked 32nd out of the tested approaches at matching that ideal ordering.

Metric Ideas on the Table

Most of the variation in the candidate metrics comes down to three design decisions: how to group layout shifts over time, how large those groupings are, and how to summarize the groupings into a single score.

Grouping Shifts by Windows

  • Tumbling windows: Split time into fixed, non-overlapping chunks. Simple, but a shift that straddles a boundary lands in the wrong bucket and results can be brittle to timing differences of even a few milliseconds.
  • Sliding windows: Consider all possible windows of a fixed length. This gives more flexible groupings at the cost of "repeat" counting when the same cluster of shifts fits in multiple windows.
  • Session windows: Start a new group at each shift and extend it until a quiet gap appears. This identifies bursts of instability cleanly, although unbounded, it can still suffer from the same unbounded growth as CLS when shifts never stop. Tests used a capped variant to limit this.

Windows Sizes and Summary Statistics

Beyond windowing style, size makes a big difference:

  • No window (each shift standalone)
  • 100 ms
  • 300 ms
  • 1 second
  • 5 seconds

Summarization strategies included percentile picks (max, 95th, 75th, median), the mean, budget-based counts of shifts over a threshold, and non-windowed approaches like total shift divided by time on page.

Leading Candidates

From 145 permutations tested against the ground truth, three families performed about equally well. Each is a meaningful departure from how CLS currently operates.

Maximum of Long Windows

Three windowing strategies performed well at the 95th percentile and at the maximum: 1-second sliding windows, and session windows with a 1-second gap, both capped at 5 seconds and uncapped. The team prefers the maximum over the 95th percentile here because it avoids interpolation artifacts with only a handful of windows per page.

Average of Session Windows with Long Gaps

Taking the average of uncapped session windows separated by 5-second gaps also ranked highly. This variant has a useful property: if layout shifts never pause long enough to create multiple sessions, the entire page lifetime becomes one window with the same score as the current CLS. It also ignores idle time entirely—focusing only on the shifting moments.

Maximum of Short Windows

The maximum of a 300 ms sliding window came out strong as well. Shorter windows don't suffer as much from percentile interpolation concerns, but the sliding approach creates overlapping duplicates of any shift spanning multiple frames. The maximum is the simplest and clearest way to summarize this.

Approaches That Failed

Attempts to reflect the "average" experience across both stable and unstable periods all ranked poorly: medians, 75th percentiles, and shift totals divided by time spent online underperformed. Budget-based strategies—counting the percentage of shifts that crossed a minimum score—generally failed too. A variant that averaged the excess over a budget did nearly as well as the best average-of-sessions strategy, but the team dropped it in favor of the simpler formulation.

To guard against overfitting, the team validated rankings against freshly recorded videos and traces, and the tested metrics generalized well. They are now asking the web development community for input on which of the three strategies is most practical and intuitive to work with. Feedback and questions can be directed to the team via the WICG layout-instability repository or the #layout-instability channel on the Chromium Slack.

Validation and developer input

Large-scale field checks

With the leading strategies prototyped in Chrome, the next stage is to rank a wide sample of real sites and compare how each candidate behaves, and how much each deviates from CLS. The questions to answer:

  • Which sites end up ranked very differently under CLS versus one of the new candidates, and is there a sensible explanation once you inspect them?
  • Where do the candidates themselves diverge most, and does that reveal a concrete strength or weakness for any one approach?
  • If all pages are bucketed by session duration, do long-lived loads show the anticipated improvement in acceptable layout shift without creating surprises on short visits?

What remains the same

The proposal intentionally leaves a large part untouched. None of the candidates alter the per-frame layout shift score—the calculation, the JavaScript PerformanceObserver events raised for shift entries, and the rects surfaced in Chrome DevTools and WebPageTest all stay as they are. Only the way multiple frame scores get summarized into a single page value changes.

Support for whichever metric wins will follow the established path: inclusion in the web-vitals library, documentation on web.dev, and exposure through product tooling such as Lighthouse.

Considering the trade-offs

The candidates divide on whether to average the values of a big window or report the worst window seen. For a tab left open for a long time, an average gives a more representative picture; a maximum window gives a single, actionable event that a developer can trace to a timestamp and a set of shifted elements.

On windowing semantics—sliding versus session windows—it's similarly a preference question worth weighing. There is also the issue of how interpretation changes when a short-lived page is examined under each model, which the field data and the ranking comparisons above are meant to expose.

How to get involved

You can run the candidate metrics against any site today using the provided JavaScript snippets for a PerformanceObserver-based implementation, or install the experimental branch of the Core Web Vitals extension.

Send comments to the web-vitals-feedback Google group with "[Layout Shift Metrics]" in the subject line.