Cumulative Layout Shift: Measure and Avoid Visual Instability

Karolina Szczur

Karolina Szczur

May 12, 2021

Illustrated by

 Jeffrey Phillips

The experience of browsing the web can often be frustrating. Remember that when you were reading an article, something suddenly shifted, and you lost where you were? Or you were browsing a store, external widgets or ads loaded, and you suddenly clicked on something you have no interest in? Or worse, erroneously checked out or completed another action that’s hard to back out of without contacting support?

Unexpected layout shifts cause range frustrations and troubles. Fortunately, there’s a metric that helps diagnose them: Cumulative Layout Shift (CLS).

In this post, we explain what CLS is, how to measure and improve it so that you can ensure a positive, frustration-free experience for your audience.

What is Cumulative Layout Shift?


Cumulative Layout Shift measures how much elements move unexpectedly during a page view session, until there’s a five second window of no recorded shifts.


Cumulative Layout Shift refers to the sum of page layout shifts—each time the browser has to repaint an area on the screen unexpectedly, without being prompted by the viewer. It’s a measurement that portrays the overall visual stability of a page and is one of Core Web Vitals—key user experience metrics that are a part of search ranking signals since June 2021.

Tip

Cumulative Layout Shift calculation excludes shifts occurring within 500 milliseconds of viewer input. This means that certain types of intentional, human-initiated shifts don’t contribute to CLS. See Layout Instability Specification for more details.

How to monitor CLS?

Cumulative Layout Shift measurements are collected directly by the Chrome browser based on real people’s sessions. You can also gather initial page-load Cumulative Layout Shift in a lab (synthetic) setting. There are differences in reporting based on how you track Cumulative Layout Shift:

Synthetic (lab) monitoring CLSReal user monitoring (field) CLS
Measured only within the initial page load and cut off accordingly to simulated height of the device or browser. Represented as a single data point for initial load in the specified testing setting.Measured cumulatively during the entire session lifecycle. Often reported as p75 CLS, which includes varied real user scenarios and network speeds under one measurement.

Because of these differences, it’s likely the lab-reported Cumulative Layout Shift will be lower than what people experience when browsing your sites and using your applications. Until Cumulative Layout Shift is improved for the lab settings such as Lighthouse (which is happening as the Chrome Speed Team is soliciting feedback), the most reliable strategy is to use synthetic and real user monitoring tools to keep an eye on CLS.

You can monitor Cumulative Layout Shift using continuous web performance monitoring tools like Calibre, or in development mode, on your machine, using Chrome Developer Tools. To view field data, use CrUX data exposed in PageSpeed Insights, Google Search Console Speed Report or collect Web Vitals using the web-vitals JavaScript library.

The benefit of pairing lab and field testing is having a clear picture of your audience’s real-world experience and reliable tracking and the ability to reproduce issues in a synthetic setting. Field data is an aggregation of tens of thousands of data points, while lab testing creates a known baseline of a predefined user experience setting (such as a slow mobile device or a fast desktop).

While lab results won’t be the same as Google-reported field Web Vitals, it’s an indicator of your Cumulative Layout Shift baseline. With both types of tools in use, you have a bulletproof tracking system to improve speed metrics.

What is a fast CLS score?

Each speed metric has a recommended range we can set performance budgets against to make sure user experience doesn’t suffer. Cumulative Layout Shift is measured differently from other metrics (reported in seconds or milliseconds) in a way that it’s a unitless value (a score).

Cumulative Layout Shift desired values showing anything under 0.1 as good, between 0.1 and 0.25 as needs improvement, and above 0.25 as poor.

To provide a fast and optimal experience, we should strive for a CLS score below 0.1. A reading above 0.25 is categorised as poor (very likely having a negative effect on your audience).

Good CLS MeasurementPoor CLS Measurement
≤ 0.1> 0.25

How to improve CLS?

There are several common reasons why your Cumulative Layout Shift might not be fast:

  • Images, ads, iframes and embeds without specified dimensions
  • Unoptimised webfont delivery and display
  • Inefficient CSS animations
  • Late-injected JavaScript content

Set size and accurate placeholders for media and ads

Images, ads, iframes and any embeds will cause a layout shift if the browser can’t predict their size. Always include width and height attributes for imagery, including responsive images (here’s a fantastic implementation walkthrough).

When dealing with iframes, ads and embeds, investigate the predictable size of the element and statically reserve space for it. The closest the reserved area is to the actual dimensions, the less likely the shift is. Avoiding placing ads and widgets at the top of the viewport is also going to be helpful. Since Cumulative Layout Shift is a stability metric, you aim to create the most predictable loading and viewing experience.

Optimise webfont delivery

When using webfonts, it’s easy to introduce rendering and shift issues, such as:

  • Flash of Unstyled Text (FOUT): the fallback font is displayed while the browser is waiting to download the webfont files, often resulting in jarring shifts and flashes.
  • Flash of Invisible Text (FOIT): webfonts not being displayed because they are take a long time to download, resulting in blank pages.

To avoid font-related layout shifts, we have to deliver webfonts as critical assets and use the font-display:optional property to avoid layout recalculations. If your fallback font is displayed even momentarily, how visually similar it is to the webfont will also matter. You can test this behaviour with the Font Style Matcher tool by Monica Dinulescu:

How Font Style Matcher helps you visualise webfont shifts and choose better font fallbacks.

Use efficient CSS animations

When animating elements, it’s essential to minimise layout and repaints. Not all animation techniques are equal. To keep your Cumulative Layout Shift in check, use transform CSS property when working with motion and avoid absolute positioning (top, right, bottom, left) and margin or padding to animate the position of elements. Changes to specific CSS properties will cause layout, paint and composite changes, so familiarise yourself with CSS triggers:

CSS Triggers showcases how and if each CSS property causes the browser to perform layout operations, re-paint pixels and composite them together.

CSS Triggers shows how and if a CSS property causes the browser to perform layout operations, re-paint pixels and composite them together.

Image carousel animation can be notorious for causing unwanted layout shifts (and present questionable user experience and conversion value), so they are best to be avoided when focusing on Cumulative Layout Shift improvements.

Avoid late-injected JavaScript content

If your page is slow to initialise and JavaScript fetches and renders content (for example, a search box, a third-party embed or the latest data for a widget) by making more API or AJAX requests, it will affect Cumulative Layout Shift.

To avoid shifts, render content statically or server-side, so it’s always present. Another strategy to combat JavaScript-related shifts is to use mock skeleton screens that resemble the content that’s to be rendered (in size and placement), so re-layouts are less jarring.

You can visualise and inspect Cumulative Layout Shift on your websites using the Cumulative Layout Shift Debugger:

Visualisation of Cumulative Layout Shift on Calibre’s blog using Cumulative Layout Shift Debugger.

What’s the future of CLS?

Performance metrics change. This is especially true for the new generation of measurements, such as Core Web Vitals, that have seen regular updates, bug fixes and recent developments. Cumulative Layout Shift is no different.

Recently, in Chrome versions between 88 and 89, there have been numerous changes to CLS calculation, which might have affected your reporting. You can keep up-to-date with those developments in the Cumulative Layout Shift changelog maintained by the Chrome Speed Team.

Based on the feedback and experimentation on CLS, some of the mechanics behind the metric calculation and its naming will change in tools like Lighthouse soon. While some details aren’t finalised yet, we will likely see a few variants of CLS under different names. These changes address the feedback for Cumulative Layout Shift and aim to make the difference between initial load and page lifetime load CLS more obvious.

Karolina Szczur

Karolina Szczur

Karolina is a Co-founder and Product Design Lead at Calibre. With years of design experience under her belt, she’s responsible for the comprehensive user experience spanning over product, visuals and content. Find her on Mastodon or LinkedIn.

Get the latest performance resources, every two weeks

We will send you articles, tools, case studies and more, so you can become a better performance advocate.

This newsletter is easily the best performance publication we have.

Harry Roberts

Harry Roberts

Consultant Web Performance Engineer