Skip to content

Glossary CLS

What Is CLS?

Definition

Cumulative Layout Shift (CLS) measures how much a page's content moves on its own while the user is looking at it. Google rates it good up to 0.1; shifts following a user interaction do not count.

A sunken, uneven patch of setts in a cobbled street — beside the title CLS
The setts sank after they were laid
On this page 5
  1. What CLS measures
  2. What counts and what does not
  3. The four usual causes
  4. Why the lab misleads here
  5. Common mistakes
In brief

Why "cumulative" does not mean summing the whole visit, which shifts fall out of the calculation and why, the four causes that show up in almost every audit, and why the lab test misleads here more than with any other metric.

A sunken, uneven patch of setts in a cobbled street — beside the title CLS
The setts sank after they were laid

What CLS measures

Cumulative Layout Shift measures how much a page's content moves on its own while the user is looking at it. It counts neither pixels nor seconds but a unitless score combining two things: how much of the screen was affected and how far the moving part travelled.

Google rates a value up to 0.1 as good, up to 0.25 as needing improvement, and above that as poor. As with the other field metrics, assessment runs on the 75th percentile of real visits, not on a lab test, exactly as with LCP and INP.

The word "cumulative" in the name misleads, because the whole visit is not summed. Since 2021 the highest-scoring session window is taken: a stretch of at most five seconds in which the jolts follow one another with gaps under a second. A long page with scattered shifts does not accumulate a huge value merely for being long.

That detail matters more in practice than it sounds. Before the change, a lengthy article or an infinitely loading list scored worse than a short page with the same fault, which rewarded thin pages without their behaviour being any better.

The formula is worth understanding, because it explains what a change actually fixes. Each jolt's score multiplies two fractions: the share of screen affected and the distance travelled relative to the visible height or width. A narrow banner dropping a long way can score the same as a large block dropping a little.

From that follows something counter-intuitive: moving a small element right at the top usually costs more than moving a large one at the end of the page, because it drags everything after it. The most rewarding fixes therefore sit almost always in the header of the CMS template rather than in the article body.

What counts and what does not

Here sits the metric's most expensive misunderstanding. Not every movement is penalised: shifts occurring within 500 milliseconds of a user interaction are treated as expected and stay out of the calculation.

That is consistent. If someone opens an accordion and the content below moves down, that is exactly what they asked for. Penalising it would force rigid interfaces just to satisfy a metric, which is the opposite of what the metric is trying to achieve.

The practical corollary is that the worst scores come not from interactive interfaces but from content arriving late: an ad banner, a consent notice, a font replacing another, an image without declared dimensions. All of that happens unasked, and so it counts in full.

That 500-millisecond rule has an edge worth knowing. It applies to the interaction, not to what the interaction triggers: if a click starts a request that takes two seconds and then moves the content, that movement falls outside the window and counts in full.

This is where the most frequent shop case sits: a catalog filter reloading results. The user clicks, nothing visible happens, and two seconds later the list jumps. Formally they caused it; for the metric and for the user it is an unexpected jolt. The fix is reserving the space and showing a loading state where the result will appear.

What the user triggers is not charged to the page

The four usual causes

Images and videos without dimensions. The most common cause and the easiest to fix: declare width and height on the tag, or set an aspect-ratio in CSS, so the browser reserves the gap before it has the file. This intersects directly with lazy loading, because a deferred image arrives even later and the jump is more visible.

Ads, embeds and notices. A block whose size is not known in advance pushes everything below it when it appears. The fix is reserving the minimum space up front, even if a gap remains when the block never arrives.

Fonts swapped during load. The browser paints first with a system typeface and switches once the final one arrives; if their metrics differ, the whole text reflows. This is controlled with font-display and with fallback fonts of similar proportions.

Content inserted above what is already being read. An offer message appearing at the very top pushes the article down exactly when the user had found the paragraph they wanted. This case is pure UX and needs no metric to be noticed.

There is a fifth cause missing from the usual lists and turning up regularly in audits: the measurement code itself. Heatmap tools, pop-up surveys and notification bars loaded through Google Tag Manager insert themselves by definition after the first paint, which is the worst possible moment.

It deserves checking as regularly as everything else: every script added for a campaign is a candidate for moving content, and because it is installed through an interface without touching the template, it passes no technical SEO review. Reserving a fixed strip for the notification bar, instead of letting it push, solves the case completely.

Why the lab misleads here

CLS is the metric where lab tests and real data diverge most, and the reason is simple: an automated tool loads the page and stands still. It does not scroll, does not accept the cookie notice, and does not wait for the banner that arrives after eight seconds.

The real user does all of that, and many of the worst shifts happen precisely while scrolling, when blocks come into view that had no space reserved. A green lab result with a red field result is therefore not a contradiction but the normal case.

For the work that means: look at the data in Google Search Console first, and use the lab only to reproduce a known case. A heatmap helps show how far people actually scroll, because that is where to look.

To reproduce a specific case in the browser there is a short path: open the performance panel, record while scrolling slowly through the page, and look at the layout shift markers on the timeline. Each names the culprit element, and it is almost always the same one across a whole template.

Then compare against what people actually do. If traffic arrives mostly on mobile, test on mobile, because mobile-first indexing decides and width changes which blocks push which. And as with the other field metrics, values take weeks to move, so measuring the next day says nothing.

Common mistakes

  • Redesigning an interface so nothing ever moves, when user-triggered movement does not count at all.
  • Giving dimensions only to article images and forgetting the ad slots, which push the hardest.
  • Trusting the lab test, which neither scrolls nor accepts the consent notice.
  • Fixing a template and measuring the next day: the field window covers 28 days, just as with LCP and INP.
  • Treating CLS as a cosmetic issue. A jump at the moment of clicking "buy" changes what gets clicked, and that comes straight out of CRO work and of conversion.
Manuel Riveiro Rodriguez CEO & Digital Strategist

A technical audit covers this and everything else in one pass.

Request an audit

Frequently asked

Does the shift count when I open a menu?

No. Shifts occurring within 500 milliseconds of a click, tap or key press are treated as expected and stay out of the calculation. Only movement the user did not cause is penalised.

Why is my CLS good in the tool and bad in Search Console?

Because the tool loads the page and stands still: it does not scroll, does not accept the cookie notice, and does not wait for the late banner. The worst shifts happen precisely during real use, so the difference is expected rather than a measurement error.

Is setting width and height on images enough?

It fixes the most common cause, not all of them. Ad slots, third-party embeds, consent notices and the font swap during load remain. The general rule is to reserve space for anything that will appear later, image or not.

How does this relate to lazy loading?

Closely, and in the uncomfortable direction. A deferred image arrives later, so without declared dimensions the jump is even more visible than without deferring. The two techniques go together: lazy loading plus explicit dimensions, never the first without the second.

Does poor CLS cost sales?

It can cost them directly, not just through annoyance. If content jumps at the instant the user presses, the click lands elsewhere: on a different product, on an ad, on a button they did not want. That is where the metric stops being technical and shows up in the till.