How to Test and Fix CLS: A Practical Layout Shift Debugging Guide

CLS, Cumulative Layout Shift, measures how much visible content moves unexpectedly while someone uses a page. You've felt it: you go to tap a link and the page jumps, and you tap an ad instead.

Each individual layout shift gets a score based on two things: how much of the viewport moved (impact) and how far it moved (distance). CLS then groups shifts into session windows, bursts of shifts close together in time, and reports the worst burst.

• Good: 0.1 or less.
• Needs improvement: above 0.1 up to 0.25.
• Poor: above 0.25.
• Judged at the 75th percentile of page loads in field data.

Shifts that don't count

Layout shifts that happen shortly after a user interaction, like clicking a button that expands a section, are excluded. Movement people expect isn't unexpected. Animations using CSS transforms also don't trigger layout shifts, because they don't move layout.

Before debugging anything, check whether real users actually experience poor CLS. Lab tests load a page once, often without scrolling, ads or consent banners behaving as they do for visitors.

1. 1Search Console Core Web Vitals report. Shows URL groups flagged for CLS on mobile and desktop.
2. 2PageSpeed Insights field section. Shows real-user CLS for the URL or origin when enough data exists.
3. 3Your own real user monitoring. If you collect web vitals from visitors, this is the most detailed source.

Here's the workflow I use. It usually finds the culprit in minutes.

1. 1Run PageSpeed Insights or Lighthouse and open the layout shift diagnostic, which lists the elements that shifted most.
2. 2Open Chrome DevTools, Performance panel. Record a page load, including scrolling. Layout shifts appear as a track you can click to see which nodes moved.
3. 3Turn on Layout Shift Regions. In DevTools rendering settings, this highlights shifting areas in real time as you use the page.
4. 4Throttle the network and CPU. Slow conditions expose shifts that fast machines hide.
5. 5Test with consent banners, ads and logged-out states the way real visitors see the page.
6. 6Use the web-vitals library with attribution in the field to log which element caused the largest shift for real users.

Images and videos without dimensions

When the browser doesn't know an image's size, it allocates no space, then pushes content down when the image loads. Fix: set width and height attributes, or use CSS aspect-ratio, so space is reserved.

Ads, embeds and iframes

Ad slots and embeds often load late and expand. Fix: reserve a fixed minimum height for the slot, based on the most common ad size, and avoid collapsing empty slots in a way that shifts content.

Cookie banners and top notices

A banner injected at the top of the page pushes everything down. Fix: overlay banners at the bottom or as a fixed layer that doesn't move content, or reserve their space from the first render.

Web fonts

When a web font replaces a fallback font with different metrics, text reflows. Fix: preload key fonts, and use font metric overrides so the fallback font takes up similar space.

Late-loading components

Related posts, reviews widgets and personalized blocks injected above existing content cause shifts. Fix: load them below the fold, or reserve their space with a placeholder of the right size.

Client-rendered apps and hydrated frameworks create their own layout shift patterns.

• Content that appears after hydration. Server render the structure with correct dimensions, so hydration fills content without changing layout.
• Skeleton screens with the wrong size. A placeholder that's shorter than the real content still shifts. Match real dimensions.
• Data-driven lists. Reserve space for the expected number of items, or render below the visible area.
• Route changes in single-page apps. Soft navigations can shift content in ways traditional page load metrics don't capture well. Test the flows users actually take.

If rendering itself is a problem for search, the JavaScript SEO play covers crawl and index implications.

Some CLS behavior only shows up in real browsing patterns, and it explains why field data sometimes improves or worsens without any layout change on your side.

Back-forward cache

When a page is restored from the browser's back-forward cache, it can appear instantly in its previous state, without the loading sequence that causes shifts. Pages that are eligible for this cache often see better field metrics on back and forward navigations. Things like certain unload handlers can make pages ineligible.

Long visits and infinite scroll

Because CLS reports the worst burst in a session window, long-scrolling pages with content loaded as you go can produce poor windows deep in the page. Test the full scroll journey, not just the top of the page.

Logged-in and personalized states

Personalized modules, recommendations and account banners can shift layout for logged-in users only. If your field CLS is poor but anonymous testing looks fine, test logged in.

You shipped the fix, the lab score is green. The Search Console report may still show poor for weeks. That's normal: field data is based on a rolling window of real visits, so improvements appear gradually.

• Validate in Search Console once the fix is live, and watch the trend.
• Keep real user monitoring running so you see improvement before the report updates.
• Add a CLS check to your release process. A new banner, widget or ad partner can undo months of work overnight.
• Watch third-party changes. Tag managers let non-developers inject elements that shift layout.

1. 1Confirm poor CLS in field data, and note mobile vs desktop.
2. 2Record a throttled load with scrolling in DevTools and identify the shifting elements.
3. 3Set dimensions or aspect-ratio on all images, videos and iframes.
4. 4Reserve fixed space for ad slots and embeds.
5. 5Move or overlay cookie banners and top notices so they don't push content.
6. 6Preload key fonts and align fallback font metrics.
7. 7Render late components below the fold or with correctly sized placeholders.
8. 8Re-test in the lab, then track field data until it confirms the fix.

CLS work is usually part of a broader technical SEO review. Fix templates, not individual URLs, so one change repairs every page that uses them.