SEO

Cumulative Layout Shift (CLS)

Also called CLS, layout shift

A Core Web Vitals metric that scores how much page content moves unexpectedly while someone is viewing it; 0.1 or less is good.

Quick facts: Cumulative Layout Shift (CLS)

Category
SEO
Also called
CLS, layout shift
Level
Intermediate
Affects
Page experience, mis-taps on mobile, form completion, conversion rate
Where to see it
Google Search Console Core Web Vitals report, PageSpeed Insights, Chrome DevTools Performance panel, Lighthouse
In this article4
  1. How Cumulative Layout Shift works
  2. Why it matters
  3. Common mistakes
  4. How to act on it

Cumulative Layout Shift (CLS) is a measure of how much the visible content of a page jumps around unexpectedly while someone is using it. It is one of Google’s three Core Web Vitals, and it scores visual stability: a low number means the page stays put, a high number means text, buttons and images move under the reader’s eyes.

How Cumulative Layout Shift works

Every time an element already on screen changes position without the user causing it, the browser records a layout shift. Each shift is scored by multiplying two things: how much of the viewport the moving content occupies (the impact fraction) and how far it moved relative to the viewport (the distance fraction). A banner that pushes a whole article down by a third of the screen scores far higher than a small icon nudging a few pixels.

Shifts are grouped into bursts called session windows. A window closes after one second with no new shifts, or after five seconds in total, and the page’s CLS is the score of its worst window rather than the sum of every shift across a long visit. Shifts that happen within half a second of a click, tap or key press are excluded, because content moving in response to the user is expected.

Google’s thresholds are simple: 0.1 or less is good, above 0.25 is poor, and anything in between needs improvement. For the Core Web Vitals assessment Google uses the 75th percentile of real visits recorded in the Chrome User Experience Report (CrUX), so a page passes only if at least three in four visits stay at or under the threshold.

Why it matters

Layout shift is the most irritating of the speed problems because it causes mistakes. Someone goes to tap “Call now” on a plumber’s site, an advert loads above it, and they tap something else. On a checkout page the same jump can mean the wrong item in the basket or an abandoned order. Those moments cost enquiries whatever Google makes of them.

CLS also feeds Google’s page experience signals. It is a modest ranking factor that will not lift a weak page above a better answer, but between two similar pages the stable one has an edge. UK sites have one culprit worth checking first: the cookie consent banner. A banner injected at the top of the page after load, pushing everything down, can produce a poor CLS score on its own, on every page of the site.

Common mistakes

  • Images and videos without dimensions. If the browser does not know how tall an image will be, it reserves no space and the text below jumps when the file arrives.
  • Ads, embeds and widgets with no reserved slot. Review widgets, map embeds and ad units often load late and then expand.
  • Content inserted above what people are reading. Promotional bars, consent banners and “related posts” blocks added by JavaScript near the top of the page.
  • Web fonts that swap at a different size. When the fallback font is replaced by the brand font with wider or narrower letters, lines rewrap and paragraphs move.
  • Judging by a single lab test. A Lighthouse run on a fast connection may show no shift at all, while real visitors on slower phones see plenty, often further down the page.

How to act on it

Start with real-user data. The Core Web Vitals report in Google Search Console groups URLs by status, and PageSpeed Insights shows field CLS for a single URL or the whole origin when Chrome has collected enough visits. Then open Chrome DevTools: the Performance panel highlights each shift and the element that moved, which tells you where to look.

Most fixes are straightforward. Add width and height attributes, or a CSS aspect ratio, to every image and video. Give ad slots, embeds and dynamic widgets a fixed minimum height. Show consent banners as an overlay fixed to the top or bottom of the viewport instead of inserting them into the page flow. Match your fallback font’s metrics to the web font and preload the main font file. Animate with CSS transforms, which do not trigger layout shift, rather than by changing top, height or margin.

Re-test after each change, but expect field data to take around four weeks to catch up, because CrUX reports a rolling 28-day window. If you would rather have someone trace and fix the causes across every template, that is routine work in a technical SEO engagement.

Do and do not

Do

  • Set width and height on every image and video
  • Reserve space for ads, embeds and widgets
  • Show cookie banners as overlays rather than in the page flow

Do not

  • Insert content above what the reader is already viewing
  • Rely on a single Lighthouse run
  • Animate layout properties such as top or height

Questions people ask about this

What is a good CLS score?

Google treats a CLS of 0.1 or less as good and anything above 0.25 as poor. The score that counts for the Core Web Vitals assessment is the 75th percentile of real visits over the previous 28 days, so most of your visitors need a stable experience, not just you on office broadband. Aim for comfortably under 0.1 on your key templates so a slow ad or font does not tip you over.

Can a cookie banner cause layout shift?

Yes, if it is inserted into the page and pushes content down after the page has started to display. A banner that sits as an overlay, fixed to the top or bottom of the screen, does not move the content beneath it and so does not add to CLS. You still need a compliant banner under UK GDPR and PECR; the fix is how it is positioned, not removing it.

Why is CLS fine in Lighthouse but poor in Search Console?

Lighthouse is a lab test: it loads the page once on a simulated device and stops measuring once loading settles. Search Console uses field data from real Chrome users, which captures shifts that happen while people scroll, on slower connections and on different screen sizes. When the two disagree, trust the field data and reproduce the problem by scrolling through the page with DevTools recording.

Related terms

Found this useful?

Share it, or ask an AI to summarise it

Back to the glossary

Knowing the term is the easy part

Applying it to your own site and budget is the work. Book a call and I will tell you what actually applies to you.