How to Fix Cumulative Layout Shift (CLS): Causes and Fixes

Google’s web.dev reported that The Economic Times improved CLS from 0.25 to 0.09 and cut bounce rates by 43 per cent overall, alongside faster LCP, as part of a wider Core Web Vitals project.

Cumulative Layout Shift is fixed by giving every element its space before it arrives: dimensions on images and embeds, reserved slots for ads and banners, and fallback fonts that match your web fonts closely. This guide shows you how to find the exact element that is moving, why it moves, and which fix to apply to each cause.

What Cumulative Layout Shift actually measures

Cumulative Layout Shift (CLS) is the Core Web Vital that measures visual stability. It records how much visible content moves unexpectedly while someone is using the page.

Each individual shift gets a score based on two things: how much of the viewport the moving elements occupy, and how far they travel relative to the viewport. Shifts that happen close together are grouped into a session window, and the page’s CLS is the largest of those windows rather than the total of every shift across the whole visit. That detail matters for long pages and single page apps, because a small shift during scrolling later on will not simply stack on top of the shifts from the initial load.

Two points trip people up:

• Expected movement does not count. Shifts that happen shortly after a user interaction, such as opening an accordion they clicked, are excluded. CLS is about movement the user did not ask for.
• Animations using transform do not count. Moving an element with CSS transform does not trigger a layout shift. Animating top, left, height or margin does.

CLS thresholds and how Google judges your pages

Google’s thresholds for CLS are:

CLS score	Rating	What it usually means
0.1 or lower	Good	Content stays put, or only tiny shifts occur
Above 0.1 up to 0.25	Needs improvement	One or two noticeable jumps, often a font swap or an image
Above 0.25	Poor	Large blocks of content are moving, often from ads, banners or embeds

The score Google uses for assessment comes from field data, meaning real visits recorded in the Chrome User Experience Report, not from a single lab test. A lab tool such as Lighthouse only sees the shifts that happen during its simulated page load. It will miss shifts caused by a cookie banner that appears after a delay, an advert that loads once the user scrolls, or content injected after a click elsewhere on the page. This is why a page can look clean in Lighthouse and still fail in the field. If you want the wider context on how CLS sits alongside the other metrics, my overview of Core Web Vitals and what each one measures covers the full picture.

How to find the element that is shifting

In my experience almost every CLS problem traces back to a short list of causes: images without dimensions, web font swaps, injected banners, ads and embeds, content added by JavaScript, and late-loading CSS. Guessing which one applies wastes time, so identify the exact element and the moment it moves before you change any code.

1. Start with field data. Check the Core Web Vitals report in Google Search Console to see which groups of URLs have a CLS problem on mobile and desktop. Then run a representative URL through PageSpeed Insights, which shows field data for that URL or its origin when enough data exists. This tells you whether the problem is real and how widespread it is.
2. Run a lab test for clues. The Lighthouse report in PageSpeed Insights lists the elements that contributed most to layout shift during its test. Treat this as a starting list, not the full answer.
3. Turn on layout shift highlighting in Chrome DevTools. The Rendering panel has an option to highlight layout shift regions. With it on, reload the page and any area that shifts flashes briefly. Scroll, wait for banners, and interact as a real visitor would.
4. Record a performance trace. In the DevTools Performance panel, record a page load. Layout shifts appear in the timeline, and selecting one shows which nodes moved and where they moved from and to. Look at what loaded just before the shift: a font file, an image, a script or a stylesheet.
5. Test on a throttled mobile profile. Many shifts only appear on slower connections, where fonts and ads arrive later. Use the network and CPU throttling options so the timing resembles your real mobile visitors.
6. Collect attribution from real users if the cause is still unclear. Google’s open source web-vitals JavaScript library has an attribution build that reports the largest shifting element. Sending that to your analytics tells you exactly which element moves for real visitors, including shifts that only happen after scrolling.

Once you know the element and the trigger, the fix is usually obvious. The sections below cover each cause in turn.

Fixing images, videos and iframes

When the browser does not know how tall an image will be, it reserves no space. The image downloads, the browser works out its size, and everything below is pushed down. The fix is to tell the browser the shape in advance.

• Add width and height attributes to every image. Modern browsers use these to calculate an aspect ratio before the file arrives, even when CSS makes the image responsive. WordPress adds these attributes automatically for images inserted through the media library, but page builders, sliders and custom theme templates often strip them.
• Check lazy-loaded images. Lazy loading is fine for images below the fold, but a lazy-loading script that swaps a tiny placeholder for a full image without dimensions will cause shifts as the user scrolls.
• Give iframes a fixed size or a CSS aspect-ratio. YouTube embeds, maps, booking widgets and social posts are frequent offenders because they arrive late and expand.

Fixing web font shifts with metric overrides

When a page uses a web font, the browser often shows text in a fallback font first and then swaps to the web font once it downloads. If the two fonts have different widths and line heights, every line of text reflows. On a text-heavy page that reflow can be the single biggest source of CLS.

You have three practical options, and they can be combined:

1. Preload the most important font file so it arrives sooner and the swap happens earlier, ideally before first render. Only preload the one or two files used above the fold, because preloading everything competes with other critical resources.
2. Match the fallback font to the web font. Define a custom @font-face for your fallback, based on a local system font, and adjust it with the size-adjust, ascent-override, descent-override and line-gap-override descriptors. When the fallback takes up the same space as the web font, the swap changes how text looks but not where it sits. Some frameworks and font tools can generate these values for you; otherwise tune them by comparing the two fonts in the browser until lines wrap identically.
3. Choose a font-display value deliberately. The swap value shows text immediately but guarantees a swap. The optional value lets the browser skip the web font if it is not ready quickly, which removes the shift entirely at the cost of some visitors seeing the fallback font.

Fixing banners, ads, embeds and late CSS

Banners and notices. Cookie consent bars, promotional strips and “free delivery” announcements are often injected at the top of the page after load, which pushes the entire layout down. Either render them in the initial HTML so they are present from the first paint, or position them as overlays (fixed to the bottom of the viewport, for example) so they sit on top of content rather than inside it.

Ads. Ad slots should have a reserved container with a minimum height that matches the most likely ad size for that slot. If an ad does not fill, keep the space or show a house placeholder rather than collapsing the slot, because collapsing is itself a shift.

Dynamic content. Review widgets, related products and “you might also like” blocks loaded by JavaScript should render inside a placeholder with a set minimum height. Skeleton screens work well here.

Late-loading CSS. If a stylesheet that controls layout loads after the page has already rendered, the layout snaps from one shape to another. Make sure layout-critical styles load in the head, be careful with plugins that defer all CSS, and avoid setting up a mobile menu or hero section with JavaScript that changes dimensions after first paint. Optimisation plugins that “remove unused CSS” can cause exactly this problem when they get it wrong, so test after enabling them.

Mobile pages are where these issues hurt most, because narrow viewports make each shift a larger fraction of the screen. My guide on optimising Core Web Vitals for mobile goes into mobile-specific layout patterns.

A CLS fix checklist you can work through

• Every img has width and height attributes, including those output by sliders and page builders.
• Video embeds, maps and iframes sit inside containers with a defined aspect-ratio.
• The main web font is preloaded, and the fallback font has metric overrides so lines wrap the same way.
• Cookie and promotional banners are either in the initial HTML or positioned as overlays.
• Ad slots have reserved minimum heights and do not collapse when empty.
• Layout-critical CSS loads before first render and is not deferred by an optimisation plugin.
• You have re-tested with layout shift highlighting on a throttled mobile profile.
• You are watching field data in Search Console to confirm the fix over the following weeks.

Layout shift is one part of the experience. If your pages also feel sluggish when people tap buttons or open menus, read my guide to Interaction to Next Paint and how to improve it. And if the main content itself takes too long to appear, the problem may sit lower down, which I cover in hosting, caching and CDN upgrades for faster LCP.

Questions people ask about CLS

Why does PageSpeed Insights show good lab CLS but a poor field score?

The lab test only records shifts during a short simulated load without scrolling or interaction. Real visitors scroll, wait for delayed banners and trigger lazy-loaded content, so shifts that happen later are captured in field data but not in the lab. Use DevTools highlighting while scrolling, or the attribution build of the web-vitals library, to catch them.

Does a cookie consent banner always cause layout shift?

No. A banner causes a shift only when it is inserted into the normal page flow and pushes other content. A banner fixed to the bottom or top of the viewport as an overlay does not move existing content, so it does not add to CLS. Check how your consent tool positions the banner and change it to an overlay if it is inserted inline.

Is font-display: optional better than swap for CLS?

For CLS alone, optional is safer because the browser will not swap fonts late in the load. The trade-off is that some first-time visitors see your fallback font. If brand typography matters, use swap together with a metric-matched fallback so the swap does not move text.

How long after a fix will Search Console show improvement?

Field data is gathered over a rolling window of real visits, so the report changes gradually rather than immediately. You can ask Search Console to validate a fix, and it will track the affected URLs over the following weeks. Lab tools will confirm the fix straight away, which is a useful sign while you wait.

CLS is often one of the quicker Core Web Vitals to fix once the moving element is identified, but finding it across templates, plugins and third party scripts takes patience. If you would rather have someone trace it for you, my Core Web Vitals optimisation service covers layout stability alongside loading and responsiveness. You can also request a free audit and I will point out what is shifting on your key pages.