CLS Too High: How to Diagnose and Fix It

What this check flags

Cumulative Layout Shift measures visual stability. Every time an element moves after it has been rendered, without the user triggering that movement, the page collects a shift score. Google's thresholds are blunt: 0.1 or less is good, anything over 0.25 is poor, and the gap between them is the "needs improvement" zone where rankings and users both quietly suffer. CLS is one of the three Core Web Vitals, alongside LCP and INP.

One critical detail people miss: the score that matters is field data at the 75th percentile. Google looks at real Chrome users visiting your page and asks whether at least 75 percent of those visits stay at or under 0.1. A clean lab run on your fast office connection proves nothing if real visitors on mid-range phones watch your layout reshuffle itself. Our field vs lab data guide covers why these two numbers so often disagree.

The thresholds at a glance

CLS is unitless: it multiplies the fraction of the viewport that moved by the distance it traveled, then sums those across the page's lifetime. That's why one late banner across a wide screen can wreck a score that individual small shifts never would.

What causes layout shifts

Nearly every CLS problem traces back to one of five culprits:

Images and iframes without width and height. The browser has no idea how tall an image is until it downloads it, so it renders the page with zero space reserved, then shoves everything down when the image lands.

Web fonts swapping in. Your fallback font renders first, then the web font arrives with different metrics and every line of text reflows. That is the classic flash of unstyled text turning into a layout shift.

Ads and embeds injecting themselves. Third-party scripts that insert a 280px-tall ad unit into a 0px-tall container are a layout shift machine, and they often fire late, when the user is already reading.

Banners pushing content down. Cookie notices, promo bars, and "subscribe" strips injected at the top of the viewport shove the entire page downward after first paint.

Animating layout properties. Animating top, left, height, or margin forces the browser to recalculate layout on every frame, and neighboring elements get dragged along.

Cause to fix, mapped

Quick wins, in priority order

1. Put dimensions on every image

This is the single highest-impact fix and it costs nothing. With width and height attributes set, modern browsers compute the aspect ratio and reserve the space before the file downloads:

<img src="hero.webp" width="1200" height="630" alt="Product hero">

Keep your responsive CSS (max-width:100%; height:auto) and the ratio still holds.

2. Reserve slots for ads and embeds

Give every ad container and third-party embed a min-height matching the largest creative likely to load. An empty reserved box is invisible to the user; a box that grows under their thumb is not:

.ad-slot { min-height: 280px; }

3. Tame your web fonts

Use font-display: optional or swap deliberately, preload your critical font file, and define a fallback with size-adjust so the swap barely moves a pixel:

@font-face{ font-display:swap;
  font-family: "Inter-fallback";
  src: local("Arial");
  size-adjust: 107%;
 }

4. Animate with transform only

Replace animations on top, left, height, and margin with transform: translate() and transform: scale(). Transforms run on the compositor and never trigger layout shifts.

The classic rage-click scenario

You know this one because it has happened to you. You go to tap "Add to cart," and in the exact instant your finger commits, a late-loading banner shoves the page down and you tap "Delete item" or some damn newsletter popup instead. That is CLS in its purest, most user-hostile form. It is the reason this metric exists, and it is the reason visitors abandon carts and never come back. Every shift you eliminate is one fewer mis-tap between a visitor and your conversion.

How to detect it

Work through these in order, from real-user data down to the exact shifting element:

1. PageSpeed Insights. Shows your field CLS from real Chrome users at the top and a lab measurement below. The "Avoid large layout shifts" audit names the specific elements doing the shifting.
2. CrUX. Query the Chrome UX Report (via the API or the BigQuery dataset) to see the 75th-percentile CLS Google actually evaluates, segmented by phone and desktop.
3. Chrome DevTools. Open the Performance panel, record a page load, and look for Layout Shift entries. Enable "Layout Shift Regions" in the Rendering drawer and Chrome highlights every shifting element in blue, in real time.
4. The web-vitals library. Drop in Google's web-vitals JS library and log the onCLS() callback, which reports the metric plus the DOM node responsible, straight from your real visitors.
5. Search Console. The Core Web Vitals report groups failing URLs by issue type, so you find every template with a CLS problem, not just the one page you happened to test.

For the full methodology, work through our CLS complete guide.

How to fix it

Once DevTools has named the shifting element, the fix follows the cause-to-fix table above: reserve space for it before it loads. Set dimensions on every image and iframe (not just the hero), give ad and embed slots a fixed min-height, reserve or overlay banners instead of injecting them into the flow, and swap layout-property animations for transform. Deploy, then re-check the field data, it lags your fix by roughly a month.

Common mistakes

Fixing only the lab number and declaring victory while field data stays red. Setting dimensions on hero images but ignoring every thumbnail and logo below the fold. Hiding the cookie banner with JavaScript after it loads instead of reserving its space or overlaying it. Lazy-loading images at the top of the viewport, which guarantees a shift on every visit. And testing only on desktop, when mobile is where shifts hit hardest and where Google segments its thresholds separately.

FAQ

Does CLS count shifts the user causes, like opening an accordion?

No. Shifts that happen within 500 milliseconds of a user interaction are excluded. Only unexpected movement counts against you.

My PageSpeed lab CLS is 0 but the field score fails. Why?

Lab tests load the page once, cold, without scrolling. Real users scroll, trigger lazy loads, and receive late ads. Diagnose with DevTools while scrolling the full page, not just the initial viewport.

How long until Google sees my fix?

Field data in CrUX is a rolling 28-day window, so expect roughly a month after deployment before your new CLS score is fully reflected.

Which page's CLS does Google use, mine or the template's?

It's scored per URL, but if a shared template element (an unreserved header ad, say) causes the shift, every page using that template fails. Fix it at the template level and the whole group recovers at once.