Cumulative layout shift is the Core Web Vital for visual stability. You have felt it: you go to tap a link, an advert loads above it, and you tap something else. The MDN glossary entry for CLS puts it precisely: “Cumulative Layout Shift (CLS) is a usability metric for websites, designed by Google as one of the Core Web Vital metrics. It measures the extent to which users encounter unexpected layout shifts, in which elements of the page are moved in an unexpected way: that is, that are not the result of a user action like pressing a button or part of an animation.” This post covers the thresholds, how the score is built, the usual causes and the fixes.
The cumulative layout shift thresholds
Unlike the other two Core Web Vitals, CLS is not a time. It is a unitless score that combines how much of the viewport moved and how far it moved. Google’s guidance on web.dev sets the bands below, assessed at the 75th percentile of page loads like the rest of Core Web Vitals.
| Rating | CLS at the 75th percentile | What it usually means |
|---|---|---|
| Good | 0.1 or less | The page holds still while it loads |
| Needs improvement | Above 0.1, up to 0.25 | Noticeable jumps on some loads or templates |
| Poor | Above 0.25 | Content moves enough to cause misclicks |
Two details in the web.dev definition matter in practice. First, shifts that happen within 500 ms of a user input are excluded, so content expanding because someone tapped an accordion does not count against you. Second, the score is not a total for the whole visit, which is explained in the next section.
How the score is calculated
The name suggests every shift on the page is added together over the whole visit. That is not how it works, and the difference changes what you should fix. web.dev describes CLS as “the largest burst of layout shift scores” that happens during the life of the page.
A burst is called a session window. Shifts are grouped into the same window when there is “less than 1-second in between each shift and a maximum of 5 seconds” in total. Each window gets a score, and the page’s CLS is the worst window. In plain terms, one bad moment decides the score. A page that shifts once badly during load scores worse than one with several tiny, widely spaced shifts.
That has a practical consequence. You do not need to remove every movement on the page; you need to find the worst cluster and break it up. Usually that cluster sits in the first few seconds of loading, when images, fonts and adverts all arrive at once.
What causes layout shift
The causes are well known and few. The table below maps each one to the fix that usually resolves it.
| Cause | Why it shifts | Usual fix |
|---|---|---|
| Images and videos without dimensions | The browser does not know their size until they load | Set width and height attributes or a CSS aspect ratio |
| Web fonts | Text re-flows when the fallback font is swapped for the web font | Load key fonts early and choose a fallback with similar metrics |
| Ads and embeds that resize | The slot grows when the creative or widget arrives | Reserve a fixed space for the slot |
| Content injected above existing content | Everything below is pushed down | Insert new content below the viewport or into reserved space |
The first cause is the one MDN names directly: shifts may be caused by “<img> or <video> elements that are not given width and height attributes”. It is also the easiest to fix, which makes it the place to start.
The received wisdom is that layout shift is a developer problem buried in the theme. On many content sites it is closer to an editorial and commercial one: images pasted into posts without dimensions, embeds dropped into articles, and ad slots added by a plugin after launch. Fixing the template once does not help if every new post brings the problem back, so the habits of whoever publishes matter as much as the code.
How to fix cumulative layout shift
The principle behind every fix is the same: tell the browser how much space something will need before it arrives. Layout shift is not caused by slow loading as such. A slow image in a reserved box causes no shift at all; a fast image without one still does.
Give media its dimensions. Add width and height to every image and video. Modern browsers use them to work out the aspect ratio and reserve the box before the file downloads, even when CSS scales the image to fit its container. For elements without intrinsic size, such as an embedded player, set the ratio in CSS:
Reserve space for adverts. Ad slots are the most common cause of shifts on monetised content sites, because the creative size is often not known until the auction finishes. Give each slot a minimum height that matches its most likely size. If you use automatic placement, our post on AdSense Auto ads covers the trade-off between convenience and control, and our guide to header bidding explains why auctions can delay when a slot fills.
Tame the fonts. Preload the one or two fonts used above the fold and pick a fallback whose size and spacing are close to the web font, so the swap moves little.
Stop injecting content above the reader. Cookie banners, newsletter bars and late-loading related-content blocks often push the page down after it has rendered. Overlay them, or place them where they do not move existing content.
How to measure it and what it is worth
Start in the Core Web Vitals report in Search Console, which groups URLs by status using real-user data. Our guide to a failed Core Web Vitals assessment explains how to work through it. Then reproduce the shift in Chrome DevTools, where the performance panel highlights the elements that moved. For the loading side of the same report, see our post on Largest Contentful Paint; fixes to one sometimes affect the other.
As a ranking factor, CLS carries the same modest weight as the rest of Core Web Vitals. Relevance outweighs it. The stronger argument is commercial: misclicks on shifting pages frustrate readers, and on ad-funded sites accidental clicks on adverts are a problem rather than a bonus.
One limitation to keep in mind: lab tools only see shifts during the load they record. Shifts that happen later in the visit, from late adverts or slow third-party widgets, may only appear in field data, so a clean Lighthouse run does not prove a clean CLS. Fix what you can reproduce, then watch the field figure over the following weeks.
Frequently asked questions
What is a good CLS score?
0.1 or less at the 75th percentile of page loads. Above 0.25 is rated poor.
Do shifts after a click count towards CLS?
Not if they happen within 500 ms of the user input. Those are treated as expected and excluded.
Is CLS the total of every shift on the page?
No. It is the largest burst of layout shift scores, grouped into session windows, so the worst cluster of shifts sets the score.
What is the quickest CLS fix?
Add width and height attributes to images and videos, so the browser reserves their space before they load.
The takeaway Find the worst burst of shifts, identify what moved, and reserve space for it before it arrives. Images, fonts and adverts cover most cases.
