Fixing Layout Shift (CLS): The Overview

Why CLS fails and where to look first

A layout shift happens when something that is already visible changes position because something else changed size or appeared above it. The CLS score for a visit is the total of the worst burst of shifts, and the score Google uses is the 75th percentile of those visit scores across real Chrome users over 28 days, for mobile and desktop separately.

CLS is often the quickest of the three Core Web Vitals to fix, because the cause is normally one element on a shared template. Once you know which element moves, the fix is usually a few lines of HTML or CSS. The hard part is the finding, and the most common mistake is trusting a lab test that never saw the shift at all.

The eight causes behind most failures

This page stays at the level of finding and triage. Each guide in the right-hand column goes into its cause in detail, with code for that case.

Why your CLS numbers disagree

CLS causes more confusion between tools than any other metric, because a lab test and a real visit are measuring different things.

• A lab test only watches the load. Lighthouse loads the page once, does not scroll and does not click. Shifts caused by images lazy-loading further down, a sticky header changing height on scroll, or a pop-up after ten seconds never happen in the test.
• Real visits last longer. The browser keeps measuring for the whole time the page is open. A long article with an advert that loads halfway down can fail in the field while scoring zero in the lab.
• Real visitors see the consent banner. Depending on how your test is set up, a lab run may or may not show the same cookie banner and personalised content a first-time visitor gets.
• Screens differ. A shift that affects a large part of a narrow phone screen scores higher than the same shift on a wide desktop, because the score depends on the share of the viewport that moved.

So the rule is simple: use field data from the Core Web Vitals checker or Search Console to decide whether you have a CLS problem, and use real-user attribution to find which element is responsible. Only then use lab tools to reproduce and test the fix.

What is not counted

Movement within half a second of a tap, click or key press is excluded because the visitor caused it, so an accordion opening when clicked does not count. Animations using CSS transform do not count either. Shifts during scrolling are still counted. The CLS Debugger fixes page explains exactly how each shift is scored and grouped.

Capturing the element that shifts for real visitors

The web-vitals library's attribution build reports, for the worst burst in each visit, the element that moved most and when it happened. A few days of this data tells you more than any number of lab runs.

import { onCLS } from 'web-vitals/attribution';

onCLS(({ value, rating, attribution }) => {
  sendToAnalytics({
    metric: 'CLS',
    value: Number(value.toFixed(3)),
    rating,
    target: attribution.largestShiftTarget,   // CSS selector of the element that moved most
    shiftValue: attribution.largestShiftValue,
    shiftTime: Math.round(attribution.largestShiftTime),
    loadState: attribution.loadState,
    width: window.innerWidth
  });
});

Group the results by target and width. A selector such as main > article > p tells you that ordinary text moved, so the cause is something above it growing. The time and load state narrow it further: a shift at 300 milliseconds while the page is still loading points to fonts or images; one at several seconds after load complete points to adverts, embeds or banners.

Watching shifts directly in the browser

For a quick look on a single page, paste this into the DevTools console, then reload and use the page as a visitor would. Each shift is logged with the elements that moved.

new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.hadRecentInput) continue;
    console.log(entry.value.toFixed(4),
      entry.sources.map(s => s.node));
  }
}).observe({ type: 'layout-shift', buffered: true });

Remember the element listed is the one that moved, not the one that caused it. If a paragraph moves, look at what sits directly above it and grew.

The fix, step by step

Where CLS usually comes from on each platform

WordPress

Older themes and some page builders output images without dimensions, and sliders often start at zero height and grow once their script runs. Cookie notices and "announcement bar" plugins frequently push the whole page down. Check theme and plugin output before writing custom CSS. The CLS in WordPress guide covers theme and plugin fixes.

Shopify

Review apps, "frequently bought together" blocks and currency or shipping bars injected by apps are the usual suspects, alongside product galleries whose images have different shapes. See CLS in Shopify.

React, Next.js and single-page apps

Components that render a spinner of one height and then content of another, data fetched on the client after the first paint, and hydration differences between server and client HTML all produce shifts. Route changes in a single-page app can also add shifts to a long-lived session. See CLS in React and Next.js.

Hand-written and static sites

These are usually the easiest to fix because you control every tag. The common gaps are missing image attributes in older content, third-party embeds pasted in as raw iframes, and a web font loaded from an external service without a matched fallback.

Edge cases that catch people out

• Shifts you cannot see. A shift of one or two pixels across a large area can still score. Layout Shift Regions will flash even when the movement is hard to notice.
• Sticky headers that shrink. A header that changes height as you scroll moves everything below it. Keep its height fixed and animate with transform instead.
• Lazy-loaded images further down. Lazy loading is fine for CLS as long as each image has its dimensions; the problem is a zero-height placeholder, not the lazy loading.
• Carousels. A carousel that moves slides by changing left or margin can register as shifts. Moving slides with transform avoids this.
• Back and forward navigation. Pages restored from the back/forward cache start a fresh measurement, so shifts on the original load are not repeated. Pages excluded from that cache load again and may shift again.
• Infinite scroll and "load more". New items appended below the viewport do not shift visible content. Items inserted above, or a footer that jumps as content loads, do.

Keeping CLS below 0.1

• Make dimensions part of your content rules. Every image, video and embed gets a known shape before it loads, whether it is added by a developer or an editor.
• Give every third-party slot a box. Ads, review widgets, chat launchers and embeds live in containers with a set minimum height or aspect ratio.
• Overlay, do not insert. Banners, notices and toasts sit on top of the page rather than pushing it down.
• Keep attribution reporting on. A new plugin, app or advert placement can bring CLS back overnight. Your own data will show the new selector within days.
• Check new templates with layout shift regions on a phone width and a slow connection before they go live.

For the scoring rules and a tool that lists every shift on a page, see the CLS guide and the CLS Debugger fixes linked above.