What Is Cumulative Layout Shift?
What is CLS? Cumulative Layout Shift (CLS) is a Core Web Vitals metric that measures unexpected visual movement during a page’s lifecycle. These shifts can occur when images lack reserved space, ads load dynamically, fonts change text layout, or content is inserted above existing elements. A good CLS score is 0.1 or less. This guide explains how CLS is measured, what causes layout instability, how to diagnose shifts, and which practical fixes can make pages more visually stable.
Maybe an image appears above the paragraph. An advertisement pushes the article downward. A button shifts just as you are about to click it.
That movement is more than an annoyance. It is a sign that the page is visually unstable.
Cumulative Layout Shift (CLS) is the Core Web Vital used to measure this kind of unexpected movement during a page’s loading and usage.
Unlike LCP, which is measured in seconds, CLS is represented by a score. A lower score is better.
For most pages, the target is straightforward:
- Good: 0.10 or lower
- Needs improvement: above 0.10 up to 0.25
- Poor: above 0.25
CLS is not measuring whether a page has animations or movement in general. It is concerned with unexpected layout shifts that can disrupt what the user is doing.
Quick Answer
CLS measures how much visible page content moves unexpectedly while a page is being used.
A low CLS score means the layout remains relatively stable.
A high CLS score usually means something is being inserted, resized, replaced, or otherwise changing the position of existing content after the user has already started viewing the page.
Common causes include:
- Images without reserved dimensions
- Ads and dynamically inserted content
- Embedded videos or social posts
- Web fonts changing text layout
- Content inserted above existing content
- Late-loading UI elements
- Incorrectly sized responsive components
The goal is not to eliminate every visual change. The goal is to prevent changes that happen without the user’s expectation or interaction.
Why Does CLS Matter?
Layout stability affects how confidently someone can interact with a page.
Consider an article with a large button near the top of the screen. A visitor moves the pointer toward it, but an advertisement loads above the button and pushes it several hundred pixels lower.
The visitor may click something else.
The same problem can happen with navigation menus, forms, product listings, article links, cookie controls, and other interactive elements.
On a news site, an unexpected shift can make a reader lose their place. On an ecommerce page, it can cause a user to select the wrong product or miss an important control.
Good CLS therefore has a practical purpose: keep the interface where the user expects it to be.
CLS is also one of the three Core Web Vitals used to evaluate real-world page experience alongside LCP and INP.
A good CLS score does not guarantee high search rankings by itself, but poor page experience can make a site harder and more frustrating to use.
How Is CLS Measured?
CLS is different from LCP and INP because it does not represent a duration.
Instead, it represents the amount of unexpected visual instability observed during a page visit.
The calculation is based on two concepts:
- Impact fraction
- Distance fraction
The impact fraction describes how much of the viewport is affected by the elements that moved.
The distance fraction describes how far those elements moved relative to the viewport.
These values are combined to determine the score of an individual layout shift.
A simplified representation is:
Layout shift score = impact fraction × distance fraction
The overall CLS measurement then considers layout shifts that occur during the page’s lifecycle, with the scoring system designed to avoid unfairly penalizing pages simply because users keep them open for a long time.
The important practical point is that CLS is not simply counting how many times something moves.
A tiny movement and a large movement affecting a significant portion of the screen do not have the same impact.
What Counts as a Layout Shift?
A layout shift occurs when a visible element changes its position from one rendered frame to another without that movement being triggered by a user interaction.
For example, imagine this structure:
Article heading
Article paragraph
Advertisement
Article image
If the advertisement initially has no reserved space and then loads with a height of 300 pixels, everything below it may move downward.
The browser has effectively had to rearrange the page.
That movement can contribute to CLS.
Another example is an image:
<img src=”photo.jpg” alt=”Example photo”>
If the browser does not know the image’s dimensions before the image loads, the page may initially render with little or no space for the image.
When the image arrives, the browser has to make room for it.
A better implementation reserves the appropriate space:
<img
src=”photo.jpg”
width=”1200″
height=”800″
alt=”Example photo”>
The browser can then establish the image’s aspect ratio and reserve space before the resource finishes loading.
That simple difference can prevent a very common source of layout instability.
What Does Not Necessarily Count as a CLS Problem?
Not every movement on a webpage is bad.
For example, a visitor clicks an accordion and the content below it moves downward because the user explicitly requested the accordion to open.
That type of movement is different from an advertisement suddenly appearing above the content without the user doing anything.
User-initiated changes can be treated differently by the layout-shift measurement system.
This distinction is important because a stable website does not mean a completely static website.
Modern interfaces use:
- Menus
- Accordions
- Modals
- Carousels
- Expandable sections
- Notifications
- Dynamic content
The objective is not to freeze the interface.
It is to make changes predictable.
CLS Thresholds: What Is a Good Score?
The current Core Web Vitals thresholds are:
| CLS Score | Rating |
| 0.10 or lower | Good |
| Above 0.10 to 0.25 | Needs improvement |
| Above 0.25 | Poor |
For Core Web Vitals reporting, the 75th percentile is used.
That means you should not judge a page solely from one test run.
A laboratory test might show a CLS score of 0.02 while real visitors experience a considerably different result because their devices, connections, viewport sizes, browsers, and page interactions differ.
This is one reason field data is so important when diagnosing Core Web Vitals.
Why Can CLS Be Different Between Lab and Real Users?
Laboratory tools operate under controlled conditions.
Real visitors do not.
One visitor may load your page on a fast desktop connection. Another may use an inexpensive mobile phone on a congested network.
They may also see different advertisements, personalization, consent interfaces, experiments, or third-party content.
The browser viewport can change what appears above the fold as well.
For this reason, a laboratory CLS score is useful for finding problems, but it should not automatically be treated as the definitive experience for every visitor.
Field data gives you a broader view of what actual users experienced.
The two types of data answer different questions:
Lab data:
“Can I reproduce a layout instability under these test conditions?”
Field data:
“Are real visitors experiencing layout instability?”
A good optimization process uses both when both are available.
The Most Common Causes of Poor CLS
There is no single cause of a high CLS score.
In practice, several patterns appear repeatedly.
Images Without Reserved Space
Images are one of the easiest ways to introduce layout shifts.
Suppose the browser starts rendering an article before a large image has finished downloading.
If the image’s dimensions are not known, the browser may initially render the following content higher on the page.
When the image arrives, the content gets pushed down.
This is why defining image dimensions or otherwise reserving the correct aspect ratio is so important.
Responsive images do not have to be fixed to one physical size. The browser can still adapt them to the viewport while knowing their intended proportions.
Advertisements That Change Page Height
Advertising can be a major source of layout instability when space is not reserved properly.
A page may initially contain an empty area:
Article
Paragraph
Article content
Then an ad loads:
Article
Advertisement
Paragraph
Article content
Everything below the advertisement moves.
The solution is usually not to remove advertising altogether. It is to design the ad container so the page knows how much space the component may require.
The exact implementation depends on the advertising system, responsive breakpoints, and available ad formats.
Dynamically Inserted Content
Websites frequently insert content after the initial render.
Examples include:
- Related-content modules
- Recommended products
- Notifications
- Newsletter prompts
- Social feeds
- Personalized recommendations
- Consent interfaces
If these elements appear above existing content without reserving space, the surrounding layout can shift.
The earlier the layout establishes its structure, the less likely it is that users will see large unexpected movements.
Web Fonts Changing the Layout
Fonts can also affect CLS.
A page may initially render text using one font and then switch to another when a web font becomes available.
If the second font has different metrics, lines can wrap differently.
That can change the height of a heading or paragraph and move everything underneath it.
Font loading therefore deserves attention when investigating unexpected shifts, particularly on typography-heavy pages.
Videos and Embeds
Video players, maps, social posts, and other embedded content often have dimensions that depend on the content or the external service.
If the browser does not have enough information to reserve the correct space before the embed appears, the surrounding content can move.
The same principle applies here: establish the component’s geometry before its content arrives whenever possible.
Content Inserted Above Existing Content
One of the simplest rules for preventing CLS is also one of the most useful:
Do not unexpectedly insert large blocks of content above content the visitor is already reading.
A newsletter box appearing between the heading and first paragraph can be disruptive.
A banner inserted above an existing navigation bar can be even worse.
If a component must appear, its position and dimensions should be predictable.
How to Find What Is Causing CLS
Knowing that CLS is poor is only the first step.
The next question is much more useful:
What moved?
Start with a performance testing tool that provides layout-shift diagnostics.
PageSpeed Insights is useful because it can show both laboratory performance information and available real-user Core Web Vitals data.
Chrome DevTools can go further when you need to reproduce the problem yourself.
Look for:
- Which elements shifted
- Where the shift occurred
- When it occurred
- Whether an image or embed was involved
- Whether content was injected dynamically
- Whether fonts changed the layout
- Whether third-party code was involved
The visual experience is often revealing.
If you record a page load and watch it carefully, you may notice something that a single numerical score does not make obvious.
A score tells you that there is instability.
The page itself often tells you why.
Using Chrome DevTools to Investigate Layout Shifts
Chrome DevTools provides performance analysis tools that can help identify layout shifts.
A practical investigation looks something like this:
1. Open the page in Chrome
Use the same page template and URL where the problem occurs.
2. Open DevTools
Open Chrome DevTools and move to the Performance panel.
3. Record a page load
Start a performance recording and reload the page.
Allow the page to finish loading before stopping the recording.
4. Inspect layout-shift events
Look for layout-shift activity in the performance timeline.
The affected elements can help reveal which component caused the movement.
5. Reproduce the page more than once
A layout problem caused by an external resource may not appear identically every time.
Advertisements, third-party scripts, network conditions, cached resources, and other variables can affect what happens during a particular run.
This is one reason a single successful test should not be treated as proof that the page is fixed.
A Practical CLS Debugging Example
Suppose a blog’s CLS score is poor.
The page looks fine when the owner opens it manually, so the problem is initially difficult to understand.
A performance recording reveals the following sequence:
- The article heading renders.
- The first paragraph appears.
- A large promotional banner loads.
- The banner takes up additional vertical space.
- The article moves downward.
- The visitor’s reading position changes.
The problem is not necessarily the banner itself.
The problem is that the page did not reserve the required space for it.
That distinction changes the solution.
Instead of removing the component, the developer can investigate whether an appropriately sized container can be established before the content loads.
This is a recurring pattern with CLS: the visible problem is often the movement, while the underlying problem is missing layout information.
How to Improve CLS
The most effective CLS improvements usually come from making the page’s geometry predictable.
Reserve Space for Images
Specify image dimensions or use a reliable aspect-ratio strategy.
For responsive images, the browser should still be able to determine the expected proportions before the image finishes loading.
Reserve Space for Ads
If advertising is part of the page, design the ad slots with known dimensions or controlled responsive behavior.
Be careful with layouts where an empty slot collapses and then suddenly expands when an ad becomes available.
Give Embeds Predictable Dimensions
Video players, maps, social posts, and other external content should have a predictable container.
The browser should not have to guess how much space the component will need.
Avoid Injecting Content Above Existing Content
If a component is going to appear after the page begins rendering, consider whether it can be positioned somewhere that does not unexpectedly displace existing content.
Review Font Loading
If text changes size or wrapping after a web font loads, investigate font metrics, fallback behavior, and the way the font is being loaded.
The correct solution depends on the site’s typography and browser support requirements.
Be Careful With Dynamic UI
Popups, banners, recommendation modules, and other interface components should be designed with layout stability in mind.
Sometimes the best solution is not to make the component disappear, but to make its appearance predictable.
What About CSS Animations?
Animations are not automatically a CLS problem.
A well-designed animation can move an element without creating the kind of unexpected layout instability that CLS is designed to capture.
However, animations can still create poor user experiences if they unexpectedly alter the page or force expensive rendering work.
For visual effects that do not need to affect surrounding layout, developers often prefer properties such as transform rather than repeatedly changing layout-affecting properties.
The broader principle is more useful than memorizing one CSS rule:
A visual effect should not unexpectedly rearrange the page around the user.
CLS and Responsive Design
Responsive layouts can introduce another layer of complexity.
An element might behave correctly on a desktop viewport but shift on a narrow mobile screen because:
- Text wraps differently
- Images use different dimensions
- Navigation changes structure
- Ads use another format
- A component changes height
- A font fallback behaves differently
This is why CLS should be checked across the layouts your visitors actually use.
Do not assume that a desktop test represents the mobile experience.
A page that is visually stable at 1440 pixels wide may behave very differently at 390 pixels.
CLS on WordPress Websites
WordPress itself does not automatically cause poor CLS.
The final result depends on the theme, plugins, page builder, advertising setup, images, fonts, embeds, custom code, and other components used by the site.
When investigating a WordPress site, look beyond the WordPress core installation.
Useful questions include:
- Is the theme reserving image space correctly?
- Does the page builder generate predictable containers?
- Are ads inserted dynamically?
- Are fonts causing text reflow?
- Are plugins injecting content?
- Are sliders or embeds changing height after load?
- Is a consent or notification system changing the page structure?
Disabling random plugins one at a time can sometimes hide the symptom without explaining the underlying problem.
A better approach is to identify the element that moved first and then trace which component controls it.
CLS vs LCP
LCP and CLS measure very different aspects of performance.
LCP asks:
How quickly does the main content become visible?
CLS asks:
How stable is the visible layout?
A page can have excellent LCP but poor CLS.
For example, the main article heading and hero image may appear quickly, giving the page a good LCP result. A few seconds later, an advertisement loads and pushes the article downward, producing layout instability.
The reverse can also happen.
A page may remain perfectly stable while taking too long to display its main content.
Improving one metric does not automatically improve the other.
CLS vs INP
INP measures interaction responsiveness.
CLS measures visual stability.
Consider an ecommerce product page.
If the page suddenly moves while the visitor is reading, that is a CLS problem.
If the visitor clicks “Add to Cart” and the interface takes too long to respond, that is an INP problem.
A modern page can therefore have:
- Good LCP
- Good CLS
- Poor INP
Or any other combination.
Core Web Vitals should be treated as complementary measurements rather than one combined “speed score.”
CLS vs Page Load Time
CLS is not a measurement of how quickly a page finishes loading.
A page can continue downloading resources while maintaining a stable layout.
Another page may finish loading relatively quickly but move several important elements while doing so.
This distinction matters when interpreting performance reports.
If a developer tries to fix CLS simply by making the entire page load faster, they may improve other metrics without addressing the actual instability.
The correct question is:
What caused the page to move?
Field Data vs Lab Data for CLS
Field data is especially valuable for CLS because real users can encounter conditions that laboratory testing does not reproduce.
For example, a real visitor may see:
- Different advertising
- Different viewport dimensions
- Different font behavior
- Different cached resources
- Personalized content
- Third-party widgets
- Different network conditions
A lab test can still be extremely useful.
If a test consistently identifies a large image, ad slot, or dynamically inserted element as the source of movement, it gives you something concrete to investigate.
The strongest workflow is therefore:
Use field data to understand the real-world problem and lab tools to investigate reproducible causes.
Common CLS Mistakes
Treating Every Movement as a Problem
Interactive websites naturally change.
CLS is concerned with unexpected layout shifts, not every animation or user-triggered movement.
Looking Only at the Score
A score of 0.18 tells you the page needs improvement.
It does not tell you what to change.
Always investigate the affected elements.
Testing Only on Desktop
Mobile layouts can behave very differently.
Check the layouts and templates that matter to your actual visitors.
Fixing Images but Ignoring Ads
Adding image dimensions is important, but it may not solve the main CLS problem if advertising or dynamic content is responsible.
Assuming a Fast Page Automatically Has Good CLS
Speed and stability are related but separate.
A fast page can still jump around.
Removing Useful Components Without Investigating
If an ad, recommendation box, or notification causes a shift, deleting it may reduce the score.
But it may also remove something valuable from the site.
First determine whether the component can be implemented without destabilizing the layout.
A Practical CLS Checklist
When a page has a poor CLS result, work through the following:
- Check image dimensions and aspect ratios.
- Inspect advertisements and their reserved space.
- Check video and iframe containers.
- Look for dynamically injected content.
- Review font loading and text reflow.
- Inspect banners and notification systems.
- Test mobile and desktop layouts.
- Use DevTools to identify the elements that shifted.
- Compare lab results with available field data.
- Re-test after making changes.
- Check whether the improvement holds across multiple runs and page templates.
When CLS Optimization Is Not the First Priority
Not every website needs to attack CLS before everything else.
If your CLS is already comfortably within the good range, spending hours trying to move it from 0.04 to 0.02 may provide little practical value compared with fixing a serious LCP or INP problem.
Prioritize the metric that is actually failing and the changes that materially improve the visitor experience.
Likewise, do not redesign an entire page just to eliminate a tiny layout shift that users are unlikely to notice.
Performance optimization should be proportional to the problem.
Final Verdict
CLS is fundamentally about trust in the interface.
When someone opens a page, they form a mental picture of where things are. If the page keeps moving unexpectedly, that confidence disappears.
The technical fixes are often straightforward once the source of the movement is identified: reserve space for images, control dynamic content, establish predictable dimensions for embeds and advertisements, and investigate font-related reflow.
The harder part is diagnosis.
A CLS score tells you that the page is unstable. It does not automatically tell you which component is responsible or what the best fix will be.
That is why good CLS optimization starts with observation rather than blindly applying performance tricks.
Find what moved.
Find out why it moved.
Then make the layout predictable before the content arrives.
That approach produces a better Core Web Vital and, more importantly, a page that feels dependable to the people using it.
Related Articles:
- What Is LCP? Largest Contentful Paint Explained
- What Is INP? Interaction to Next Paint Explained
- Core Web Vitals: Field Data vs Lab Data
- How to Fix Core Web Vitals Issues
- What Is TTFB? Time to First Byte Explained
Performance Audit CTA
If your CLS score is poor but the cause is not obvious, a performance audit can help identify which page elements are shifting, when the movement occurs, and whether the problem is isolated to one template or repeated across the site.
The goal should not be to chase a perfect number.
The goal is to make the page stable, predictable, and comfortable to use.
Recommended Resources
Use these resources to understand CLS and diagnose visual instability:
- Cumulative Layout Shift (CLS) explains the metric and its measurement.
- Optimize Cumulative Layout Shift provides practical ways to prevent unexpected layout movement.
- Google Search Central: Core Web Vitals explains Google’s guidance on user-experience metrics.
- Google PageSpeed Insights helps identify performance issues using available field data and lab diagnostics.
- Chrome DevTools Performance helps investigate browser rendering and layout behavior.