What is Cumulative Layout Shift (CLS) and how to fix it

What is Cumulative Layout Shift (CLS)?

Cumulative Layout Shift (CLS) represents the "visual stability" part of the Core Web Vitals. CLS measures how the page moves while content renders or new content appears. You notice it when you lose your place in an article you started reading, or when you click the wrong button because it moved under your finger. People sometimes call it "content layout shift", but the metric's name is Cumulative Layout Shift.

What is a good Cumulative Layout Shift (CLS) score?

A good CLS score is anything between 0 and 0.1. Between 0.1 and 0.25 it needs improvement, and any CLS score above 0.25 is considered poor. To pass the Core Web Vitals for the Cumulative Layout Shift, at least 75% of your page visits need a "good" CLS score. That's the p75 of your field data, with mobile and desktop measured separately. CLS has no unit: it's a score, where LCP and INP are times.

The Core Web Vitals report in Google Search Console groups failing URLs by issue. "CLS issue: more than 0.1 (mobile)" means needs improvement, "CLS issue: more than 0.25 (desktop)" means poor, and both thresholds exist for each device. Search Console averages your field data over a rolling window. So a fix doesn't turn the report green the day it goes live: for weeks, part of what it shows is still the old site.

What a layout shift costs you

A page that jumps around feels broken, even when everything on it works.

• Visitors and your brand: A shift interrupts whatever the visitor was doing. They lose the line they were reading or tap the wrong link, and some of them give up and leave. A site that keeps moving also looks badly built, and that reflects on the company behind it.
• Accessibility: Layout shifts hit hardest when you only see part of the page, for example when you zoom in or use a screen magnifier. One shift can push the text you were reading out of view.
• SEO and Search Ranking: Google's ranking systems use the Core Web Vitals, and CLS is one of them. It is a small factor. Google says it shows the most relevant content first, and a good page experience helps when many pages are about equally relevant.

How is CLS measured?

Browsers report layout shifts through the Layout Instability API. Paste this in the console and every shift gets logged:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Each entry has a value, which is the score of that shift, and a sources list with the elements that moved. Shifts right after a click have hadRecentInput set to true. They are logged here but don't count toward CLS.

Calculating the CLS

Every layout shift gets its own score:

layout shift score = impact fraction * distance fraction

The impact fraction is how much of the viewport the moving elements touch, counting where they were before the shift and where they ended up. The distance fraction is how far they moved, as a share of the viewport's largest dimension (on a phone, the height).

Take an element that covers half the viewport and moves down by 25% of the viewport height. Before and after together it covers 75% of the viewport. That gives an impact fraction of 0.75 and a distance fraction of 0.25, so the shift scores 0.75 * 0.25 = 0.1875. One shift like that is above 0.1 on its own. The CLS of the page adds up these shift scores per session window, explained below.

Expected vs. unexpected layout shifts

When you click a "load more items" link, you expect new items to appear and the page to move. That is why only unexpected layout shifts count toward CLS. Any shift within 500 milliseconds of a click, tap or keypress is left out of the calculation, so a dropdown menu that opens on click costs you nothing. Scrolling doesn't count as input, more on that below.

Layout shift sessions

When CLS was first introduced it added up every shift over the whole life of the page. Pages that stay open for a long time, like infinite scrollers and single-page apps, kept piling up score. Since June 2021 CLS is calculated in sessions. Each session lasts at most 5 seconds and ends after a 1 second gap between layout shifts. The session with the largest CLS score becomes the final CLS score.

Say the first session adds up to 0.095, the next to 0.15 and the last to 0. The final CLS score is the highest of the three: 0.15.

Common CLS causes

Every layout shift works the same way. After the page has rendered, an element gets bigger or smaller or changes position, and everything after it in the layout moves along. These are the usual reasons:

Images, videos and iframes without dimensions

Unsized media is one of the most common causes of CLS. The browser only learns an image's size when the first bytes of the file arrive. Until then, without a width and height (or a CSS aspect-ratio), it reserves no space and the image has no height. When it loads, everything below it moves down.

How Images and Media Cause Layout Shift covers unsized images, videos and iframes, the width: auto CSS trap, art direction, responsive image mismatches, lazy loading and placeholder images.

Web font swaps

While the web font downloads, the page renders its text in a fallback font. When the web font arrives the text reflows. Different letter widths and line heights give different line breaks, and every block under that paragraph moves.

Lighthouse's "Ensure text remains visible during webfont load" audit pushes you toward font-display: swap. For CLS that does nothing on its own: the text shows sooner, in the fallback font, and the swap still moves it. What fixes it is a fallback that takes up the same space, with @font-face metric overrides like size-adjust and ascent-override. Then deliver the font sooner by self-hosting and preloading critical fonts. The fix-and-identify guide has the code.

CSS animations and transitions

Animate top, left, width or height and the browser recalculates the layout on every frame. Each of those frames can be a layout shift. transform and opacity never trigger layout, so move things with those instead. Layout shift caused by CSS transitions walks through the fix.

Ads, embeds and dynamically injected content

Ads load late and push content down. A cookie banner that overlays the page doesn't shift anything, but one that is inserted at the top pushes the whole page down. AJAX requests do the same when they inject content without reserving space. In each case something lands on the page that the browser did not know about when it laid the page out. Reserve the space up front, for example with min-height on the container. For third-party embeds like YouTube and Google Maps, the facade pattern removes the CLS entirely.

Scroll-triggered layout shifts

A Lighthouse page-load test does not scroll, so it won't catch this CLS cause. Headers that hide on scroll, parallax effects and shrinking navigation bars often animate top or height. Scroll is not an excluding input in the Layout Instability specification, so every layout shift it triggers counts toward your CLS score. Use transform: translateY() for anything that moves on scroll. How scroll-triggered animations cause CLS has the details.

Finding and fixing CLS issues

Start with field data. A lab test only sees the first seconds of a page load, while your visitors scroll, wait for the ads and keep reading. Check the p75 CLS for mobile and desktop separately: for CLS, desktop is often the worse of the two. Google Search Console shows which groups of pages fail. A RUM tool like CoreDash also records which element shifted, so you see whether it's the product image on one template or the ad slot on another. Look at the trend too. A sudden jump usually means a release added something, like a new banner or an ad slot.

Then reproduce it in Chrome DevTools or with the Core Web Vitals Visualizer extension and find what makes it move. The step-by-step diagnosis, tool walkthroughs, code fixes for every cause and a quick-fix checklist are in Find and Fix Cumulative Layout Shift (CLS) Issues.

Case study: Rakuten 24's Core Web Vitals A/B test

Rakuten 24, a Japanese online store, optimized one high-traffic landing page for the Core Web Vitals. They ran it against the original for a month, with 50% of the traffic on each version. For CLS they reserved space for images with CSS aspect-ratio and for lazy-loaded elements with min-height. The optimized page's CLS was 92.72% lower. It also finished loading 0.4 seconds earlier in their mobile load test, with better FCP and TTFB. Compared to the original, the optimized page had:

• 53.37% more revenue per visitor
• 33.13% higher conversion rate
• 15.20% higher average order value
• 35.12% lower exit rate

CLS was the biggest improvement in the test, but load time, FCP and TTFB improved too. So these results belong to the whole optimization. Don't quote them as what CLS alone is worth.

What real-world CLS data shows

In the Chrome UX Report for August 2026, 81.5% of origins had a good CLS, up from 80.1% in August 2025.

On corewebvitals.io itself, CoreDash measures CLS as the best-performing Core Web Vital. Of all page loads, 92.8% score "good", with almost no gap between desktop (92.8% good) and mobile (92.7% good). Both have a p75 of 0, so at least three quarters of page loads had no layout shift at all.

Across the web, CLS is better on mobile than on desktop. That's the reverse of LCP and INP. The 2025 Web Almanac has the numbers, along with how often pages use the causes listed above:

• 81% of mobile sites and 72% of desktop sites have a good CLS. About 9% of mobile and 10% of desktop sites are poor.
• 62% of mobile pages have at least one image without explicit dimensions, down from 66% in 2024.
• 40% of mobile pages (44% on desktop) have non-composited animations.
• 87% of mobile pages use at least one web font, and about 12% preload one (Fonts chapter).

Related guides

These guides go deeper into finding and fixing CLS:

• Find and Fix CLS Issues: step-by-step diagnosis with tool walkthroughs, code fixes for every cause and a quick-fix checklist.
• How Images and Media Cause Layout Shift: CLS from unsized images, videos, iframes, art direction, responsive images, lazy loading and placeholders.
• Fix layout shift caused by auto sizing images: add proper dimensions to images and responsive containers.
• Fix layout shift caused by CSS transitions: find layout-triggering CSS animations and replace them with composited alternatives.
• Scroll-triggered animations and CLS: the CLS cause a Lighthouse page-load test misses, and how to fix it.
• Self-host Google Fonts: less font-loading CLS by self-hosting fonts with the right font-display and preloading.
• Ensure text remains visible during web font load: font-display and font metric overrides against font-swap layout shifts.
• Build a chat widget with perfect Core Web Vitals: a case study on adding a third-party widget without CLS, INP or LCP regressions.

The Core Web Vitals overview covers all three metrics, and the Core Web Vitals checklist helps you audit your site.