What Is CLS in Core Web Vitals? Score, Calculation and Thresholds

CLS stands for Cumulative Layout Shift. It is one of the three Core Web Vitals, the set of page experience measurements that Google publishes guidance for. Where Largest Contentful Paint (LCP) measures how quickly the main content appears and Interaction to Next Paint (INP) measures how quickly a page responds to input, CLS measures visual stability: how much visible content moves around unexpectedly while the page is in use.

A layout shift is what you experience when you are about to tap a link and the page jumps, so you tap something else. CLS turns that experience into a single number. This guide explains the metric itself: what it counts, how the score is calculated, what the thresholds mean, why lab and field numbers differ, and how to read the score in three tools. It ends with the common causes and a pointer to the step-by-step repair guide. If you already know what is moving and want to fix it, go straight to Reduce Cumulative Layout Shift (CLS) Step by Step.

Before you begin

You do not need to change anything to follow this guide. It helps to have:

The address of one page you care about, ideally a page that visitors reach from search.
A Chromium-based browser (Chrome or Edge) to try the DevTools steps.
Access to your Google Search Console property, if you have one. If not, Set Up Google Search Console shows how.

For the other two vitals, see Core Web Vitals Explained: LCP, INP and CLS Thresholds. This page stays with CLS.

What CLS measures

The browser draws a page in stages. Text, images, scripts and styles arrive at different times, and the browser places each element as soon as it knows how. A layout shift happens when an element that was already visible changes its position between one rendered frame and the next, without the visitor having asked for it.

Some examples of shifts that count:

A banner is inserted above the article and the text moves down.
An image loads with no reserved space and pushes the paragraph below it.
A web font replaces a fallback font and a heading wraps onto a second line.

Some movements that do not count:

Content that moves because the visitor scrolled.
Movement produced by CSS transform, such as a menu sliding in, because a transform does not change layout.
Shifts that begin shortly after a tap, click or key press. Browsers treat movement within about half a second of such input as expected.

The word cumulative matters: the score combines individual shifts rather than judging a single one. How they are combined has changed over time, which is explained below.

How the score is calculated

Each individual shift receives a layout shift score. It is the product of two fractions, which the specification calls the impact fraction and the distance fraction.

Layout shift score = impact fraction x distance fraction

Impact fraction. Take every element that moved between the two frames (the "unstable" elements). Combine the area they covered in the previous frame with the area they cover in the current frame, and express that combined area as a fraction of the viewport, which is the visible part of the page. An element that fills half the screen and then moves leaves a footprint larger than half, because both positions count.

Distance fraction. Find the greatest distance any unstable element moved, horizontally or vertically, and divide it by the viewport's largest dimension (its width or its height, whichever is larger). The farther the movement relative to the screen, the bigger the fraction.

A worked example in line with the one on web.dev: an element fills half of the viewport and then moves down by a quarter of the viewport height. The combined footprint covers 75 percent of the viewport, so the impact fraction is 0.75. The movement is 25 percent of the viewport height, so the distance fraction is 0.25. The shift scores 0.75 x 0.25 = 0.1875, which is already worse than the "good" limit on its own.

Two consequences follow. A big element moving a short distance and a small element moving a long distance can score about the same. And the metric has no unit: a CLS of 0.1 is just a number, not seconds or pixels.

Session windows: how shifts are added up

Early versions of the metric simply added every shift during the whole life of the page, which unfairly penalised pages that stay open for a long time, such as single-page apps and infinite-scroll feeds. The current definition groups shifts into session windows.

A session window is a burst of shifts that follows two rules:

Each shift in the window happens less than 1 second after the previous one. A gap of 1 second or more ends the window, and the next shift starts a new one.
The window lasts no longer than 5 seconds in total. If shifts keep coming, a new window starts when the cap is reached.

Add up the scores inside each window. The page's CLS is the largest window total, not the sum of all windows. So a page with one rough moment during load and then stability is judged on that rough moment, and a long-lived page is not punished simply for staying open.

For example, if shifts of 0.02 and 0.03 occur one half-second apart during loading, that window totals 0.05. Ten seconds later, a banner causes shifts of 0.04 and 0.02 within a second of each other, a second window totalling 0.06. The page's CLS is 0.06, because that is the largest window.

Thresholds: good, needs improvement, poor

Google publishes three bands for CLS:

Rating	CLS value
Good	0.1 or less
Needs improvement	above 0.1 and up to 0.25
Poor	above 0.25

The rating applies to the 75th percentile of page loads, reported separately for mobile and desktop. If you line up all the CLS values from real visits from lowest to highest, the 75th percentile is the value that three quarters of visits are at or below. A page therefore passes when at least three in four visits are good, not when the average is. A few terrible visits will not necessarily fail a page, and a page that is steady for most visitors can still fail if a quarter of them have a bad experience.

For comparison, the good thresholds for the other vitals are 2.5 seconds for LCP and 200 milliseconds for INP, measured the same way. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Lab data and field data

You will see CLS reported two ways, and they will not always agree.

Lab data comes from a controlled test, such as Lighthouse or a DevTools recording. Conditions are fixed: one device profile, one network speed, a clean cache, and usually just the page load. Lab data is repeatable, which makes it the right tool for finding and testing a fix. Its weakness is coverage: it sees only what the test script does. A shift that happens after scrolling, after a consent choice or on the third visit may never occur.

Field data comes from real visitors. Chrome records the metric for users who opt in, and the Chrome UX Report (CrUX) aggregates it, normally over a rolling 28-day period. Field CLS covers the whole visit, from the start of the page until the visitor leaves, across many devices, connections and behaviours. It is what the Core Web Vitals assessment uses, but it is slower to change and it needs enough traffic to be reported at all. Because CrUX is built from Chrome, it reflects Chrome users.

When a lab score is excellent and the field score is poor, suspect shifts that only occur in real use: late ads, consent tools, content that loads when scrolling, or layouts that vary by screen size. When the lab score is worse than the field score, your test may be harsher than your typical visitor, for example with slow throttling. Field Data vs Lab Data walks through the comparison in detail.

How to measure CLS

Chrome DevTools Performance panel

Open the page, then open DevTools and go to the Performance panel.
Turn on mobile emulation and, if you want to expose slow-loading parts, a network throttling setting.
Click the record-and-reload button, wait for the page to finish, and stop the recording.
In the result, find the layout shift markers (the label differs slightly between Chrome versions; look for Layout Shifts or the Insights sidebar). Select a marker to see its score and which elements moved.

The Performance panel also offers a live metrics view that shows CLS for the page as you use it on your own device. That is handy for testing interactions, since you can scroll and click and watch the number change. Remember that it reflects your device and connection only.

PageSpeed Insights

Enter the address at pagespeed.web.dev. The report has two parts:

Discover what your real users are experiencing shows field data from CrUX when enough visits exist, including CLS at the 75th percentile and a pass or fail for the Core Web Vitals assessment. You can look at the single URL or at the whole origin, and switch between mobile and desktop.
Diagnose performance issues shows a Lighthouse lab run, including its CLS value and a diagnostic that lists the elements which shifted.

If the field part says there is not enough data, the page has too little traffic for its own record. Origin-level data may still appear.

Search Console Core Web Vitals report

In Search Console, open Core Web Vitals under Experience. It groups URLs with similar problems and shows how many are Good, Need improvement or Poor, separately for mobile and desktop. Select an issue such as "CLS issue: more than 0.1 (mobile)" to see example URLs. Like PageSpeed Insights, it uses field data, so changes appear slowly. After deploying a repair, the Validate fix action starts a monitoring period. The Core Web Vitals Report in Search Console describes every status and how validation works.

Common causes

These are the usual reasons real pages shift. The repair guide has code and steps for each.

Images and videos without dimensions. The browser cannot reserve space, so content after them moves when the file arrives. See Image Layout Shift: Width, Height and aspect-ratio.
Embeds and iframes. Maps, video players and social widgets grow after loading.
Ads and injected widgets. The slot fills at an unknown size, often above existing content.
Banners and notices. A cookie or promotion bar inserted after the first paint pushes everything down.
Web fonts. A swap between fallback and web font changes line wrapping. Font Display Swap covers prevention.
Late scripts. Content added by JavaScript, including third-party tags, can appear above visible text. See Third-Party Scripts and Page Speed.
Animations on layout properties. Changing height or margin moves neighbours; transforms do not.

The general fix is to reserve space before content arrives, to insert new content below what the visitor can see, and to animate with transforms.

Troubleshooting what you see

The DevTools number differs from PageSpeed Insights. They run different tests on different machines. Treat each as a reading from its own conditions, and compare them before and after a change within the same tool.

The score changes every time I test. Layout shift depends on when files arrive, which varies with network timing. Run several tests and look at the pattern rather than a single result.

Search Console shows a CLS issue but I cannot reproduce it. Field data includes devices, widths and behaviours you did not test. Check the example URLs it lists, try narrow and wide screens, scroll slowly, and interact with consent and chat widgets.

There is no field data for my page. Low-traffic pages are often missing from CrUX. Use the lab tools for diagnosis, and look at the origin-level figure if shown.

Frequently asked questions

What is a good CLS score?

A CLS of 0.1 or less is good, above 0.1 and up to 0.25 needs improvement, and above 0.25 is poor. The rating is based on the 75th percentile of page loads, so at least three in four visits should be at or under 0.1 for a page to pass.

Does CLS include shifts after the page has loaded?

Yes. In field data the metric covers the entire visit. Scrolling does not count as a shift, but late content that moves visible elements does, and each burst is scored as a session window.

Why does CLS have no unit?

It is a product of two fractions, one of area and one of distance, so the units cancel out. It is a relative score of how much of the screen moved and how far.

Does CLS affect search rankings?

Google lists Core Web Vitals among the signals used by its ranking systems for page experience, but it also states that relevance and content quality matter more. Improving CLS makes pages steadier for visitors, and it does not promise a change in rankings.

Can I measure CLS myself in code?

Yes. Browsers based on Chromium expose layout shifts through the Layout Instability API, and the open-source web-vitals JavaScript library from the Chrome team applies the session-window logic and reports the final value. Many analytics tools can collect it too.

Official references

Next step: Try the free website sample. This guide provides technical information and does not promise rankings, a perfect Lighthouse score or index inclusion.