How to Fix Cumulative Layout Shift on Your Website: A Practical Guide

What Is Cumulative Layout Shift and Why Should You Care?

You have probably experienced it yourself. You are reading an article on your phone, about to tap a link, and suddenly the entire page jumps. A banner loaded late, an image expanded without warning, or a cookie notice pushed everything down. That frustrating jolt is exactly what Cumulative Layout Shift (CLS) measures.

CLS is one of Google’s three Core Web Vitals, the metrics that directly influence your search rankings. It quantifies how much visible content moves around unexpectedly while a page is loading and while a user is interacting with it. A low CLS score means a stable, trustworthy page. A high CLS score signals a poor user experience, and Google will penalize you for it.

How CLS Is Scored

Your goal is to keep CLS under 0.1 for at least 75% of your page loads.

How to Diagnose Your CLS Problems

Before you start fixing anything, you need to know exactly where the shifts are happening. Here are the best tools for identifying CLS issues in 2026:

• Google Search Console – Check the Core Web Vitals report for pages flagged with CLS issues
• PageSpeed Insights – Run individual URLs and look at the CLS score under both Lab and Field data
• Chrome DevTools (Performance panel) – Record a page load and look for layout shift entries in the timeline
• Web Vitals Chrome Extension – Get real-time CLS readings as you browse your own site
• DebugBear or similar monitoring tools – Track CLS trends over time across your entire site

Pro tip: Google’s Layout Shift Culprits feature in DevTools now highlights the exact elements responsible for each shift. Open DevTools, go to the Performance panel, record a page load, and click on any Layout Shift event to see which DOM nodes moved and what caused it.

The 9 Most Common Causes of CLS (and How to Fix Each One)

Below is a complete walkthrough of the issues that cause the vast majority of Cumulative Layout Shift problems. We have ordered them from the most common to the least common based on what we see across client projects.

1. Images and Videos Without Explicit Dimensions

This is the single most frequent cause of CLS. When a browser encounters an <img> tag without width and height attributes, it does not know how much space to reserve. The image loads, the browser calculates its size, and everything below it gets pushed down.

How to fix it:

1. Always include width and height attributes on every <img> and <video> element
2. Use CSS aspect-ratio for responsive images so the browser reserves the correct space even before the image loads
3. For responsive layouts, combine explicit dimensions with max-width: 100% and height: auto in your CSS

Example:

<img src="hero.jpg" width="1200" height="600" alt="Hero image" style="max-width:100%;height:auto;">

This tells the browser: “This image has a 2:1 aspect ratio. Reserve the right amount of vertical space immediately.”

2. Web Fonts Loading Late (FOUT and FOIT)

When a custom web font takes time to download, the browser first renders text using a fallback system font. Once the web font arrives, the text re-renders with different character widths, line heights, and spacing. This causes a visible layout shift.

How to fix it:

• Use font-display: swap in your @font-face declarations so text is visible immediately with a fallback
• Choose a fallback font that closely matches the size and metrics of your web font. Tools like Fallback Font Generator can help
• Use the CSS size-adjust, ascent-override, descent-override, and line-gap-override descriptors to fine-tune your fallback font metrics
• Preload your most critical font files using <link rel="preload" as="font">
• Consider self-hosting fonts instead of loading them from Google Fonts or other external CDNs

Example CSS with metric overrides:

@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: swap;
}

@font-face {
  font-family: 'MyFont-Fallback';
  src: local('Arial');
  size-adjust: 97%;
  ascent-override: 105%;
  descent-override: 22%;
  line-gap-override: 0%;
}

3. Dynamically Injected Content

Any content that gets added to the page after the initial render can cause layout shifts. Common culprits include:

• Cookie consent banners
• Newsletter signup bars
• Notification banners or promotional bars
• Chat widgets
• Social media embeds
• Related content recommendations loaded via JavaScript

How to fix it:

1. Reserve space in advance. If you know a banner will appear, use a placeholder container with a fixed minimum height in your CSS
2. Use overlay patterns instead of push-down patterns. A cookie banner that overlays the bottom of the screen (using position: fixed) does not cause a layout shift. One that pushes content down does
3. Place late-loading content lower in the viewport. Content injected near the top of the page causes much larger shifts than content added below the fold
4. Use the content-visibility CSS property for off-screen sections to prevent them from affecting layout above the fold

4. Ads and Embeds Without Reserved Space

Display ads are notorious for causing CLS because they load asynchronously, often come in varying sizes, and are injected by third-party scripts you do not control.

How to fix it:

• Always wrap ad slots in a container with a defined min-height that matches the expected ad size
• If an ad slot might not fill, use a subtle background color or placeholder so the space does not look broken
• For responsive ad units, use CSS aspect-ratio containers
• Load ads lower on the page where possible

Example:

<div style="min-height:250px;width:300px;background:#f5f5f5;">
  <!-- Ad script loads here -->
</div>

5. Late-Loading CSS or Render-Blocking Issues

If your CSS loads in stages (for example, one stylesheet loads first, then another overrides it), elements can shift as styles are applied sequentially.

How to fix it:

• Inline critical CSS in the <head> so above-the-fold content is styled correctly from the first render
• Do not lazy-load CSS that affects above-the-fold layout
• Avoid using @import inside CSS files, which creates cascading network requests
• Combine and minify your stylesheets to reduce the number of render-blocking requests

6. JavaScript That Manipulates the DOM After Load

Client-side JavaScript that inserts, resizes, or repositions elements after the page has rendered is a major CLS contributor. Common examples:

• Carousels or sliders that initialize late and snap to their final layout
• Accordions or tabs that adjust height on load
• A/B testing scripts that swap content
• Personalization scripts

How to fix it:

1. Set explicit dimensions on containers before JavaScript runs
2. Use server-side rendering (SSR) or static site generation (SSG) where possible so content is present in the initial HTML
3. For carousels, define the height of the slider container in CSS based on your largest slide
4. For A/B testing, use server-side experiments or apply changes before the first paint using inline scripts in the <head>

7. Animations That Trigger Layout Changes

Not all animations cause layout shift, but any animation that changes properties like width, height, top, left, margin, or padding will trigger a reflow and potentially count toward your CLS score.

How to fix it:

• Use transform and opacity for animations instead of layout-triggering properties
• Replace top/left positioning changes with transform: translate()
• Replace width/height animations with transform: scale()

Good vs. bad animation properties:

8. Responsive Design Breakpoints That Misbehave

Sometimes CLS happens only on specific screen sizes. A component might be designed for desktop and then poorly adapted for mobile, causing elements to reflow once the viewport is calculated.

How to fix it:

• Test CLS on multiple viewport sizes, not just desktop
• Use mobile-first CSS so the base styles work on the smallest screen
• Ensure navigation menus, hero sections, and sidebars have defined dimensions for every breakpoint
• Use the aspect-ratio CSS property for responsive media containers

9. Third-Party Scripts and Widgets

Live chat widgets, social share buttons, email capture pop-ups, and analytics tags can all inject DOM elements that shift your layout.

How to fix it:

• Load third-party scripts with async or defer to prevent them from blocking rendering
• Use position: fixed or position: absolute for widgets so they overlay instead of pushing content
• Audit all third-party scripts regularly and remove any that are no longer needed
• If a widget must inject content into the flow of the page, reserve space for it with a CSS placeholder

Platform-Specific CLS Fixes

How to Fix CLS in WordPress

WordPress sites often suffer from CLS due to themes loading multiple font files, plugins injecting banners, and missing image dimensions in older content.

1. Update to WordPress 6.x or later. Modern WordPress automatically adds width and height to images uploaded through the media library
2. Use a performance plugin like WP Rocket, Perfmatters, or LiteSpeed Cache to inline critical CSS and defer non-essential scripts
3. Audit your theme. Check that the header, navigation, and hero section have fixed heights defined in CSS
4. Optimize font loading. Use a plugin like OMGF (Optimize My Google Fonts) to self-host Google Fonts and add font-display: swap
5. Check plugin output. Temporarily deactivate plugins one by one to identify which ones inject layout-shifting content

How to Fix CLS in Shopify

Shopify stores frequently have CLS issues from product image galleries, dynamically loaded reviews, and app-injected banners.

1. Use Shopify’s built-in image helpers that automatically output width and height attributes
2. Reserve space for product reviews by setting a min-height on the review container
3. Avoid lazy loading above-the-fold images. Your hero banner and first row of product images should load eagerly
4. Audit installed apps. Many Shopify apps inject scripts that cause shifts. Test with apps disabled to find the culprit
5. Use Shopify’s native section architecture to keep layout predictable rather than relying on external JavaScript

A Quick CLS Audit Checklist

Use this checklist whenever you are troubleshooting CLS on a page:

How to Verify Your Fixes Are Working

After implementing changes, you need to confirm that your CLS score has actually improved. Here is the recommended workflow:

1. Run PageSpeed Insights on the affected URLs and compare before-and-after CLS scores in the Lab data section
2. Check Field data. Lab data shows simulated results. Field data in PageSpeed Insights and Search Console reflects real user experiences. It can take 28 days for field data to update
3. Use Chrome DevTools Performance tab. Record a full page load and look for layout shift events. Click each one to see what element shifted and by how much
4. Monitor Search Console. The Core Web Vitals report will update as Google recollects data from real users visiting your site
5. Set up ongoing monitoring with a tool like DebugBear, Calibre, or SpeedCurve so you catch regressions before they affect your rankings

Frequently Asked Questions

What is a good CLS score?

Google considers a CLS score of 0.1 or below as “good.” Scores between 0.1 and 0.25 need improvement, and anything above 0.25 is rated as poor. Aim for the lowest score possible, ideally under 0.05.

Why is CLS bad for my website?

High CLS frustrates users by causing unexpected page movement. It leads to accidental clicks, lost reading position, and a feeling that your site is unreliable. From an SEO perspective, Google uses CLS as a ranking factor through Core Web Vitals, so a poor score can directly hurt your position in search results.

Does CLS affect mobile and desktop differently?

Yes. Google measures CLS separately for mobile and desktop. Mobile pages often have worse CLS because of slower network connections, smaller viewports, and content that reflows more aggressively. Always test and optimize for both.

How long does it take for CLS improvements to show in Search Console?

Google’s Core Web Vitals report in Search Console uses a 28-day rolling average of real user data (CrUX data). After you deploy a fix, it can take up to 28 days for the improvement to fully reflect in your report.

Can a single plugin or script cause CLS across my entire site?

Absolutely. A global element like a cookie consent banner, a sticky header that loads late, or a chat widget script can cause layout shifts on every single page. This is why Search Console might flag hundreds of URLs at once for CLS issues.

Do layout shifts caused by user interaction count toward CLS?

No. Layout shifts that happen within 500 milliseconds of a user interaction (like clicking a button to expand a section) are excluded from the CLS calculation. Only unexpected shifts count. This means accordions, dropdowns, and toggle menus triggered by user clicks are fine.

Final Thoughts

Fixing Cumulative Layout Shift is not a single task. It is a combination of good development practices applied consistently across your entire site. The good news is that most CLS issues come from a small number of root causes: missing image dimensions, late-loading fonts, and dynamically injected content. Fix those three categories and you will likely see a dramatic improvement in your score.

If you have been staring at a poor CLS score in your Core Web Vitals report and are not sure where to start, begin with the audit checklist above. Work through each item, test your changes, and monitor the results over the following month.

Need help diagnosing and fixing CLS on your site? Get in touch with our team at DesignSlurp. We specialize in web performance optimization and can help you get your Core Web Vitals into the green zone.