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.
