How to Fix Cumulative Layout Shift: 9 Powerful CLS Fixes

Introduction

A page can look perfectly fine after it finishes loading and still have a poor CLS score. How to Fix Cumulative Layout Shift starts with identifying the elements that move unexpectedly while a page loads or updates. Common causes include images without reserved dimensions, dynamically inserted ads, late-loading web fonts, embedded content, and interface elements added without enough space. By measuring layout shifts, checking real user and lab data, and applying targeted fixes, website owners can improve visual stability and provide a more predictable browsing experience.

The problem often happens during the moments before the page settles into its final layout. An image appears without reserved space. An advertisement is inserted above an article. A web font changes the shape of a heading. A banner pushes the content downward after the user has already started reading.

These changes may only last a fraction of a second, but they can make a page feel unstable.

Fixing CLS is therefore less about making the page load faster and more about making the browser know where things belong before those things appear.

This guide focuses on the practical side of CLS optimization: finding the elements responsible for layout shifts, understanding why they move, and fixing the underlying implementation rather than simply trying random performance settings.

Quick Answer

The most effective ways to fix CLS are:

• Set width and height attributes on images and videos.
• Reserve space for advertisements, embeds, and other dynamic content.
• Avoid inserting content above existing content after the page has rendered.
• Make sure web fonts do not cause large text or layout changes.
• Use stable containers for banners, consent notices, and promotional elements.
• Avoid animations that change layout properties such as width, height, top, or left.
• Check JavaScript that adds or modifies DOM elements after initial rendering.
• Test both mobile and desktop because the causes can differ significantly.
• Use Chrome DevTools and field data to identify the actual source of the shift.
• Fix the largest recurring layout shifts first instead of trying to eliminate every tiny movement.

A good CLS score is 0.10 or lower at the 75th percentile.

How to Fix CLS Step by Step

The fastest way to improve CLS is to stop treating it as a mysterious score.

A CLS problem usually comes from a relatively small number of page elements. Once you identify which element moves and what causes that movement, the fix is often straightforward.

1. Find the Element That Is Moving

Start with the evidence rather than changing CSS blindly.

Use tools such as:

• PageSpeed Insights
• Chrome DevTools
• Lighthouse
• Chrome’s Performance panel
• Search Console Core Web Vitals reports
• Real-user field data when available

A laboratory test can show you that layout instability exists, but the useful question is:

Which element shifted, and what caused it to shift?

For example, a report might reveal that:

• an article heading moved downward
• an image appeared after the surrounding content had already rendered
• a navigation bar changed height
• an advertisement expanded
• a cookie banner pushed content upward
• a font swap changed the dimensions of text

Do not start by installing another optimization plugin or changing your entire stylesheet.

Find the shifting element first.

2. Reserve Space for Images

Images are one of the most common causes of layout movement.

Consider an image that initially has no known height:

<img src=”hero.webp” alt=”Website performance dashboard”>

The browser may not know how much vertical space the image requires until its dimensions become available.

That can cause the content below it to move when the image is rendered.

A better implementation provides intrinsic dimensions:

<img

  src=”hero.webp”

  width=”1200″

  height=”675″

  alt=”Website performance dashboard”

>

The browser can then calculate the image’s aspect ratio before the image finishes downloading.

This does not mean every image must always occupy a fixed pixel size. Responsive images can still scale.

For example:

img {

  max-width: 100%;

  height: auto;

}

The important part is that the browser has enough information to reserve the correct aspect ratio.

What about responsive images?

Responsive images using srcset and sizes can still be CLS-safe.

The browser needs to know the intended dimensions of the rendered image, while the selected source can change depending on viewport size and resolution.

The problem is not responsive images.

The problem is unknown layout dimensions.

3. Give Video and Embedded Media a Stable Size

The same principle applies to:

• videos
• iframes
• maps
• social embeds
• product widgets
• interactive charts

Suppose an iframe initially occupies almost no vertical space and then expands when its content becomes available.

Everything below it moves.

Reserve the expected space instead.

CSS can be useful for maintaining an aspect ratio:

.video-container {

  aspect-ratio: 16 / 9;

  width: 100%;

}

Then place the embedded content inside that stable container.

This approach is especially useful for responsive layouts where the exact pixel height changes with the width of the viewport.

4. Reserve Space for Advertisements

Advertising is a particularly common source of CLS because ad dimensions can vary.

A page may initially display an article headline near the top of the viewport. Later, an ad slot loads and pushes the headline downward.

From the browser’s perspective, the layout changed.

From the user’s perspective, the page just jumped.

Instead of allowing an ad slot to grow unpredictably, design the layout around an allocated space.

For example, a container can have an expected minimum height appropriate for the ad format.

The exact dimensions depend on the advertising layout, device, and placement. There is no universal height that works for every ad slot.

The important rule is:

Reserve enough space for content that is expected to appear.

Be careful with responsive ad slots

Responsive advertising can make this harder because the final creative may vary.

If a slot can legitimately use several sizes, the page needs a strategy that prevents the surrounding content from repeatedly moving as different sizes are selected.

Possible approaches include:

• reserving a stable minimum area
• designing ad placements into the page structure
• using different containers for different breakpoints
• avoiding placements that expand above already-visible content

Do not simply add a huge fixed empty block everywhere. That may eliminate one problem while creating another user-experience problem.

The goal is predictable layout, not unnecessary blank space.

5. Stop Injecting Content Above Existing Content

JavaScript-driven content can create severe layout shifts.

Imagine this sequence:

1. The article heading renders.
2. The user begins reading.
3. JavaScript requests promotional content.
4. A banner is inserted above the heading.
5. The article moves downward.

The banner may be useful, but its timing creates instability.

This can happen with:

• promotional banners
• newsletter forms
• cookie notices
• recommendation boxes
• related-content widgets
• personalization systems
• chat interfaces
• notifications
• dynamically loaded components

If content must appear, allocate its space from the beginning or position it in a way that does not unexpectedly push existing content.

Ask a simple question

For every dynamically inserted element, ask:

“What happens to the content that is already on the screen?”

If the answer is “it gets pushed,” investigate whether the element can occupy reserved space instead.

6. Be Careful With Cookie Banners and Consent Notices

Consent interfaces deserve special attention because they can appear very early in the browsing session.

A cookie banner that pushes the entire page downward can create a large visible shift.

Depending on the design, a fixed or overlay-based implementation may avoid moving the main document content.

However, overlays have their own accessibility and usability considerations.

The goal should not be to hide every consent element simply to improve a metric.

Instead:

• make its position predictable
• avoid moving the primary page content unnecessarily
• ensure it works correctly on small screens
• make controls accessible
• prevent repeated resizing after the banner appears

7. Fix Web Font-Related Layout Shifts

Fonts can cause layout instability when fallback text and the final web font have noticeably different metrics.

For example:

1. The browser displays fallback text.
2. The web font finishes loading.
3. The font changes.
4. Text wraps onto a different line.
5. The height of the heading or paragraph changes.
6. Content below moves.

This is especially noticeable with:

• large headings
• navigation menus
• buttons
• cards
• tightly sized components
• multilingual content

The solution is not always “load the font faster.”

You should also consider whether the fallback font and final font have compatible metrics.

Useful strategies include:

• choosing a fallback with similar characteristics
• using appropriate font-display
• reducing unnecessary font variants
• avoiding excessive font families
• using metric-adjustment techniques where appropriate
• allowing important text containers enough flexibility

Font optimization should balance visual stability, readability, and loading behavior.

8. Avoid Layout-Changing Animations

Not every visual movement is a CLS problem.

Animations and transitions can be perfectly legitimate when implemented correctly.

The problem occurs when animations change layout properties in a way that causes surrounding content to move.

For example:

.box {

  transition: height 300ms ease;

}

Changing the element’s height can force surrounding content to move.

In many interfaces, animating transform can provide a more stable alternative because the visual movement does not require the surrounding layout to be recalculated in the same way.

For example:

.box {

  transition: transform 300ms ease;

}

This does not mean transform is automatically the correct replacement for every animation.

The design still needs to behave correctly.

The broader rule is:

Prefer animations that do not repeatedly change the document’s layout.

9. Check JavaScript That Changes Element Dimensions

CLS problems can come from JavaScript even when the page’s original HTML and CSS look correct.

Look for scripts that:

• add classes after load
• change element heights
• insert DOM nodes
• replace placeholder content
• load recommendations
• resize widgets
• modify navigation
• reveal hidden sections
• calculate dimensions incorrectly
• replace images or media
• inject advertising

A common pattern looks harmless:

element.classList.add(“loaded”);

But if .loaded changes the element’s height or position, it can move everything around it.

When investigating CLS, don’t just inspect the HTML source.

Inspect what the browser actually receives and changes during the page lifecycle.

10. Check Hidden Elements That Suddenly Become Visible

Some websites initially reserve no space for an element and then reveal it later.

For example:

.notice {

  display: none;

}

JavaScript later changes it to:

display: block;

If that element appears inside the normal document flow, everything below it can move.

A better implementation may reserve the necessary space from the beginning or use a layout strategy where the appearance does not displace existing content.

This is particularly important for:

• subscription boxes
• promotional messages
• login notices
• recommendation widgets
• account-specific content
• feature announcements

11. Check Sticky Headers Carefully

Sticky navigation itself does not automatically create CLS.

The problem usually occurs when the header changes dimensions after the page has already rendered.

For example:

1. A compact header appears.
2. JavaScript loads additional navigation.
3. The header becomes taller.
4. The page content moves downward.

The header should have predictable dimensions across its loading states.

Be especially careful when JavaScript changes:

• logo size
• navigation height
• padding
• font size
• menu visibility
• announcement bars
• secondary navigation

A stable header is much easier for the browser to lay out.

12. Make Placeholder Components Match Their Final Content

Skeleton screens and placeholders can help users understand that content is loading.

But a badly designed placeholder can create another layout shift.

Suppose a card placeholder is 180px tall but the final component is 320px tall.

When the real content appears, the page moves.

A better placeholder closely matches the final component’s:

• height
• width
• padding
• image ratio
• text area
• spacing

The closer the placeholder is to the final layout, the less movement occurs during replacement.

13. Do Not Reserve Space With Random Fixed Heights

There is an important distinction between reserving space and forcing an arbitrary height.

This can be dangerous:

.article {

  height: 600px;

}

If the content actually needs 900px, the fixed height can create overflow or other layout problems.

Instead, use the information you actually know.

For images, preserve their aspect ratio.

For ads, reserve the expected slot size.

For components, use a minimum size when appropriate.

For responsive elements, use flexible layout rules.

CLS optimization should make the layout predictable without turning the design into a collection of arbitrary fixed dimensions.

14. Use aspect-ratio for Predictable Media Containers

Modern CSS makes it easier to reserve space for responsive media.

For example:

.card-image {

  width: 100%;

  aspect-ratio: 4 / 3;

  object-fit: cover;

}

The browser can establish the box’s proportions before the image itself is available.

This is useful for:

• article thumbnails
• product images
• video previews
• galleries
• cards
• responsive hero media

The aspect ratio should represent the actual design.

Do not choose a ratio simply because it produces a better CLS score.

15. Check Mobile Separately

A page can have excellent CLS on desktop and poor CLS on mobile.

The reason is simple: the layout changes.

Mobile may have:

• different navigation
• taller headings
• different advertisements
• different image sizes
• different font wrapping
• stacked components
• mobile-specific banners
• different third-party widgets

A component that occupies 80px on desktop may occupy 160px on a phone.

Test the layouts independently.

When investigating field data, look at the affected device category rather than assuming the desktop implementation explains every problem.

16. Use Chrome DevTools to Find Layout Shifts

Chrome DevTools can help you move from the CLS score to the actual page element.

A practical workflow is:

1. Open the page in Chrome.
2. Open DevTools.
3. Go to the Performance panel.
4. Record a page load.
5. Look for layout shift activity in the performance timeline.
6. Inspect the affected events.
7. Identify the elements that moved.
8. Trace the code or resource responsible.
9. Reproduce the shift after making the change.

The goal is to answer three questions:

What moved?

Why did it move?

What caused the browser to change the layout at that moment?

That is much more useful than simply knowing that the CLS score is 0.24.

17. Compare Lab Data With Field Data

CLS can behave differently in a controlled Lighthouse test and in real user traffic.

Real users have different:

• devices
• viewport sizes
• connection conditions
• browsers
• geographic locations
• cached resources
• interaction patterns
• page states

A laboratory test might show one layout-shift problem while field data reveals another.

This is why CLS troubleshooting should use both types of information when available.

Use lab tools to reproduce and investigate.

Use field data to understand whether the problem is affecting actual visitors and under which conditions.

18. Why a Good Lighthouse CLS Score May Not Mean the Problem Is Gone

A local test can look excellent while real users continue to experience layout instability.

Possible reasons include:

• the problematic content loads only for some visitors
• an ad behaves differently in production
• a third-party script loads conditionally
• the affected device is mobile
• the problem occurs after the initial test window
• a particular template has the issue
• field conditions differ from the lab environment

This is one reason field data is so important for Core Web Vitals.

If real-user data says the page has a CLS problem, don’t dismiss it simply because one Lighthouse run looks clean.

19. Fix CLS in WordPress

WordPress sites can develop CLS problems through the interaction of themes, plugins, page builders, advertising systems, and third-party services.

Common areas to investigate include:

• image dimensions
• lazy-loading behavior
• page-builder sections
• sliders
• popups
• cookie banners
• advertising slots
• related-post widgets
• social embeds
• newsletter forms
• font loading
• dynamically generated blocks

Do not automatically assume the optimization plugin is responsible.

First identify the element that moved.

Then determine which theme, plugin, script, or template generated or modified it.

A useful WordPress troubleshooting process

Temporarily test the affected page with nonessential components disabled in a staging environment.

If CLS improves significantly, re-enable components one at a time until the responsible feature becomes apparent.

Do not perform major plugin or theme changes directly on a production website without appropriate backups and testing.

20. Common CLS Problems and Their Fixes

CLS Cause	Typical Fix
Images without dimensions	Add intrinsic width and height
Responsive media	Use stable aspect ratios
Ads expanding unexpectedly	Reserve appropriate ad space
Dynamic banners	Allocate space before insertion
Web font swap	Improve font strategy and metric compatibility
Late-loaded embeds	Reserve an iframe/embed container
JavaScript DOM insertion	Avoid pushing existing content
Changing header height	Stabilize header dimensions
Large popups in document flow	Use a suitable overlay or reserved container
Unstable placeholders	Match placeholder and final dimensions
Animated layout properties	Prefer layout-stable animation techniques
Mobile-only shifts	Test mobile layout separately
Third-party widgets	Delay, constrain, or remove unnecessary widgets

21. What Not to Do When Fixing CLS

Some approaches appear to solve the metric while creating a worse website.

Don’t hide content just to improve CLS

Removing useful content is not performance optimization.

Don’t add huge empty spaces everywhere

Excessive reserved space can make the page feel slow or poorly designed.

Don’t disable every third-party service

Some services provide important functionality.

Determine which ones actually cause measurable problems.

Don’t rely on one Lighthouse test

A single lab run cannot represent every real visitor.

Don’t blame images automatically

Images are common CLS contributors, but JavaScript, ads, fonts, embeds, and dynamic content can be equally important.

Don’t optimize the number before identifying the cause

A CLS score tells you that instability exists.

It does not tell you what needs fixing.

22. A Practical CLS Troubleshooting Workflow

Use this sequence when a page has poor CLS.

Step 1: Confirm the problem

Check field data if available.

Determine whether the issue affects:

• mobile
• desktop
• a particular page type
• a particular template
• the whole origin

Step 2: Reproduce it

Run the affected page through PageSpeed Insights and Lighthouse.

Test the same URL more than once if the behavior appears inconsistent.

Step 3: Record the page

Use Chrome DevTools Performance recording to observe layout shifts.

Step 4: Identify the moving element

Don’t stop at “CLS is high.”

Find the element or group of elements that actually moved.

Step 5: Find the trigger

Ask what happened immediately before the movement.

Was an:

• image loaded?
• advertisement inserted?
• font applied?
• JavaScript component rendered?
• iframe resized?
• banner displayed?
• class added?
• stylesheet applied?

Step 6: Reserve or stabilize the space

Give the browser enough information about the final layout before the content appears.

Step 7: Retest

Run the same scenario again.

Make sure the fix works at different viewport sizes.

Step 8: Check field data

A successful lab test is useful.

A sustained improvement in real-user data is better evidence that the problem is actually solved.

23. CLS Fixes by Cause

If you’re looking at a poor CLS report and don’t know where to start, use this decision process.

If an image causes the shift

Check:

• width and height attributes
• aspect ratio
• responsive image implementation
• CSS dimensions
• image replacement behavior

If an advertisement causes the shift

Check:

• slot dimensions
• responsive behavior
• placement
• delayed insertion
• whether the slot expands after rendering

If text moves

Check:

• web fonts
• fallback fonts
• font metrics
• dynamic text insertion
• heading width and wrapping

If an embedded widget moves

Check:

• iframe dimensions
• container sizing
• lazy-loading behavior
• resize events

If a banner moves the page

Check:

• whether it is inserted into normal document flow
• whether space was reserved
• whether it can be displayed without moving existing content

If JavaScript causes the shift

Check:

• DOM insertion
• class changes
• style changes
• component initialization
• asynchronous content
• third-party scripts

24. CLS and Core Web Vitals

CLS is one of the three Core Web Vitals, alongside LCP and INP.

The three metrics answer different questions.

LCP: How quickly does the main content become visible?

INP: How responsive is the page when users interact with it?

CLS: How stable is the layout while the page is loading and changing?

A page can have:

• good LCP but poor CLS
• good CLS but poor INP
• poor LCP and CLS
• good scores across all three

Improving one metric does not automatically fix the others.

For example, loading an image earlier may improve LCP, but if the image does not have known dimensions, it can still contribute to layout instability.

Performance optimization works best when these metrics are treated as related but separate problems.

25. How Much CLS Should You Aim For?

The current Core Web Vitals thresholds classify:

• Good: 0.10 or lower
• Needs improvement: above 0.10 and up to 0.25
• Poor: above 0.25

These classifications are evaluated at the 75th percentile.

But don’t treat 0.10 as a magical finish line.

A page with a CLS of 0.11 may technically be just outside the good range, while a page with 0.09 may still contain an obvious jump that users notice.

Use the metric as a signal, then investigate the actual experience.

26. CLS Optimization Checklist

Before considering a CLS issue fixed, check:

Images

• Images have known dimensions.
• Responsive images preserve their intended proportions.
• Image containers do not unexpectedly change height.
• Hero and content images have stable layout boxes.

Media and embeds

• Videos have predictable dimensions.
• Iframes have reserved space.
• Maps and social embeds have stable containers.
• Third-party widgets do not unexpectedly expand.

Advertising

• Important ad slots have predictable space.
• Ads do not unexpectedly push visible content downward.
• Mobile and desktop placements have been tested.

Fonts

• Font loading does not cause major text reflow.
• Fallback fonts are reasonably compatible.
• Unnecessary font variants have been removed.

JavaScript

• Scripts do not inject content above existing content unexpectedly.
• DOM changes have been inspected.
• Dynamic components have predictable dimensions.
• Third-party scripts have been evaluated.

Layout

• Navigation dimensions are stable.
• Banners have predictable placement.
• Placeholders resemble final components.
• Animations do not unnecessarily change layout.

Testing

• Mobile has been tested.
• Desktop has been tested.
• Lab data has been reviewed.
• Field data has been checked when available.
• The page has been tested more than once.
• The actual shifting element has been identified.

Final Verdict

Fixing CLS is fundamentally a layout problem, not simply a speed problem.

The browser needs enough information to establish a stable page before images, fonts, advertisements, embeds, and dynamic components arrive.

That makes the most reliable CLS fixes surprisingly practical:

reserve space, stabilize dimensions, control dynamic content, and stop existing content from being unexpectedly pushed around.

If your CLS is poor, don’t begin by changing everything.

Find the element that moved.

Find what caused it to move.

Then make that part of the layout predictable.

That approach produces a better result than chasing a number with random CSS changes or performance-plugin settings.

And once the change is made, check both laboratory results and real-user data. The goal isn’t simply to make a testing tool happy. The goal is a page that stays where users expect it to stay.

Related Guides

• What Is CLS? Cumulative Layout Shift Explained
• Lighthouse vs CrUX: Lab Data vs Real-World Data
• Website Speed Optimization Checklist
• Third-Party Scripts and Core Web Vitals
• Image Optimization: WebP, AVIF, Sizing and Lazy Loading
• How to Eliminate Render-Blocking Resources
• What Is LCP? Largest Contentful Paint Explained
• What Is INP? Interaction to Next Paint Explained

Recommended Resources

For accurate guidance on diagnosing and reducing CLS, explore these resources:

• web.dev: Optimize Cumulative Layout Shift: Learn common causes of layout shifts and practical ways to prevent them.
• Google Search Central: Core Web Vitals: Understand Google’s Core Web Vitals guidance and performance thresholds.
• MDN: Width and Height Attributes: Learn how image dimensions help browsers reserve layout space.
• web.dev: Optimize Web Fonts: Explore font-loading strategies that can reduce unexpected text movement.
• Google PageSpeed Insights: Measure page performance and review available diagnostic information.