Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) shows how much a webpage moves while it loads. It measures visual stability. If buttons or text jump around while the page opens, the CLS score goes up. A low CLS score means the page is steady and easier to use. This score is part of Google Core Web Vitals, which check loading speed, interactivity, and layout shift. CLS matters because sudden shifts confuse users. Google uses it to judge page experience and decide rankings. A calm, steady page helps visitors stay focused and improves trust.

Role of CLS in the Core Web Vitals framework

Cumulative Layout Shift (CLS) became part of the Core Web Vitals in 2020. This set includes three main signals that reflect how people feel when they use a webpage. Each metric checks a different part of the experience.

Largest Contentful Paint (LCP) checks loading performance. It measures how fast the main content appears.
First Input Delay (FID) checks the first response time when a user clicks or taps something.
Cumulative Layout Shift (CLS) checks visual stability, or how steady a page stays while it loads.

In 2024, Google replaced FID with Interaction to Next Paint (INP). INP looks at overall responsiveness, not just the first action. It checks delays across many taps and picks the worst one. This change makes the measure more complete. Chrome dropped FID from its reports the same year.

Google tools like Search Console and PageSpeed Insights use these signals. A page is marked as good if it scores well (75th percentile or better) on all three: LCP, INP, and CLS. Sites that pass these levels give a smoother experience. These scores also affect how a page ranks in Google search.

The idea behind Core Web Vitals is simple: if a page loads fast, reacts smoothly, and stays still while loading, it feels better to use. This helps websites stay trusted and easy to navigate.

How Cumulative Layout Shift is calculated and defined

Cumulative Layout Shift (CLS) measures how much visible content on a page moves without warning. These movements are called layout shifts. A layout shift happens when something changes position after it has already appeared on the screen. This could be text, buttons, images, or ads jumping from one place to another.

The layout instability score is based on two things:

Impact fraction: how much of the screen was affected
Distance fraction: how far the content moved

The formula is:
layout shift score = impact fraction × distance fraction

For example, if a banner that covers half the screen moves by a quarter of the screen height, the score is 0.50 × 0.25 = 0.125. The browser tracks each event using the Layout Instability API.

Only unexpected layout shifts count in the CLS score. If the user taps a button and the page moves in response, that shift is ignored. Any layout change within 500 milliseconds of a user action is excluded, as it is likely expected.

CLS session windows

Originally, CLS added up all layout shifts across the full session of a page. This was a problem for single-page applications (SPAs) or long-scrolling pages, where layout shifts could build up endlessly. To fix this, in 2021, Google changed how CLS is measured.

Now, CLS is based on the largest session window of shifts. A session window is a group of shifts that happen one after another, with less than 1 second between shifts, and up to 5 seconds total duration. The browser may detect many such windows, but it uses the one with the highest total shift score for the CLS value.

This update made CLS more accurate for modern websites. It focuses only on the worst visible instability, not the total number of shifts over time. As a result, developers see a clearer picture of what users actually experience.

Understand CLS score levels

The Cumulative Layout Shift (CLS) score is a unitless number that starts from 0. A score of 0 means the page is perfectly stable, with no layout shifts at all. The higher the number, the more unstable the layout is while loading.

Google uses three standard CLS thresholds:

Good: 0.1 or lower – page is visually stable
Needs improvement: above 0.1 up to 0.25
Poor: above 0.25 – layout shifts are clearly visible

These levels are based on research into how layout changes affect users. The aim is that at least 75 percent of real users should see a page with CLS at or below 0.1. If many users see scores above 0.25, it suggests serious layout problems that hurt the page experience.

For better usability, websites should target CLS scores of 0.1 or less at the 75th percentile of their traffic. This keeps the visual layout steady and avoids what developers call layout jank.

Common reasons for layout shifts in CLS

Cumulative Layout Shift (CLS) increases when page elements move without warning. These layout shifts usually happen during loading or content updates. Below are the main reasons:

Images or videos without set size: If an image or video loads without a fixed width or height, the browser cannot keep space ready for it. When it finally appears, it pushes other content down. This causes visible layout movement.
Ads, embeds, or iframes loaded late: Third-party items like ads or social posts can cause trouble when they load after the rest of the page. If there is no reserved space, they may shift the page suddenly. This affects visual stability.
Late content added to the DOM: When new banners, forms, or pop ups appear after the page is visible, they may push other content, especially if added at the top or middle. This happens more in live sites than during testing, due to network delays.
Web fonts and shifting text: When a custom font replaces a fallback font after loading, the text may resize and move. This causes what developers call FOIT (flash of invisible text) or FOUT (flash of unstyled text), both of which can shift nearby elements.
Animations affecting layout: Animations or transitions that change position or size of content may also cause layout shifts. Only unexpected changes count in CLS. If the movement is smooth, expected, or based on user action, it is not part of the score.

To reduce CLS, developers use tricks like skeleton loaders, aspect-ratio boxes, or adding width and height attributes to images. These techniques help reserve space before the content loads, keeping the layout stable.

How CLS affects user experience

Cumulative Layout Shift (CLS) affects how users feel while using a website. When a page moves on its own, people may lose their place, miss key information, or click the wrong button by mistake.

Impact on reading and navigation

Layout shifts can interrupt reading or scrolling. When text or images move suddenly, users may lose their place or miss part of the content. This breaks focus and makes the site feel unreliable.

Risk of wrong clicks

Unstable pages can cause accidental actions. For example, if a button moves just as someone taps it, the user might click the wrong option. This is common with buttons like “Cancel” or “Submit”, and it can lead to serious mistakes.

Trust and usability

High CLS scores damage trust. A page that keeps shifting feels unsteady. Google’s research shows that users prefer stable layouts. When things stay where they belong, people feel more in control.

Bounce rate and return visits

Bad layout stability increases bounce rates. Users are less likely to return if a page looks broken or confusing. Keeping a low CLS improves both usability and business results.

See how CLS scores improved over time

Since its release, Cumulative Layout Shift (CLS) has seen steady improvement across websites. Data from the Chrome User Experience Report and Web Almanac shows that more developers are fixing layout issues and using best practices to reduce shifts.

Desktop and mobile comparison

In 2020, only 54 percent of desktop sites and 60 percent of mobile sites reached a good CLS score (0.1 or lower) at the 75th percentile. By 2024, that rose to 72 percent on desktop and 79 percent on mobile. This means most users now view pages with better visual stability.

Surprisingly, mobile pages now have better scores than desktop. Although mobile screens are smaller and more dynamic, modern mobile browsers use back/forward cache (bfcache) more effectively. For example, Mobile Chrome skips certain events that desktop browsers still process. This lets mobile users return to cached pages without reload, avoiding extra layout shifts.

Why CLS scores improved

The rise in good scores is due to changes in development practices. Developers now:

Add width and height attributes to
Reserve fixed space for ads and
Use CSS aspect ratios and min-height
Load fonts early to avoid late
Avoid reordering dynamic elements during load

These small steps reduce sudden layout changes and improve how stable a site feels.

Even with this progress, desktop still trails mobile in average CLS. This is due in part to legacy patterns like unload handlers and no-store cache, which prevent cache reuse on desktop.

Still, the overall direction is positive. By 2025, the web has become more visually stable, meaning fewer surprises for users during page load.

Use tools to measure CLS

Developers use both field data (from real users) and lab tools (simulated tests) to measure Cumulative Layout Shift (CLS). These tools help find layout problems, check stability, and fix visual issues before they reach users.

Chrome User Experience Report (CrUX)

CrUX collects real-world CLS scores from Chrome users around the world. It reports how pages behave in actual visits, using the 75th percentile to set Core Web Vitals status. The data is public and available through BigQuery, the CrUX API, or Looker Studio dashboards. It is updated every month and powers Google tools like PageSpeed Insights and Search Console.

PageSpeed Insights (PSI)

PageSpeed Insights shows both real-user data and lab results for a given page. It uses CrUX to report field CLS scores, like “CLS = 0.04 (good).” It also uses Lighthouse to run a lab test and show a simulated score. PSI marks the score as good, needs improvement, or poor, based on Google thresholds (0.1 and 0.25). It also offers improvement tips.

Lighthouse

Lighthouse is a built-in Chrome tool that runs lab tests in a controlled setup. It loads a page like a mobile phone on a slow connection, then checks layout shift, LCP, and other performance data. Since it is a lab test, it can only detect shifts during the simulated page load. Post-load shifts from user actions are not captured. From version 7 onwards, Lighthouse also highlights which elements moved during the test, helping developers fix issues.

Web Vitals JavaScript library

Google’s web-vitals library lets site owners track CLS in real time on their own users. It uses the PerformanceObserver API to catch layout shifts and matches the values seen in CrUX. The library can also report which element caused the shift, making it useful for live debugging.

Other tools and options

PerformanceObserver API (manual setup in JavaScript)
Chrome DevTools: shows layout shifts in the Performance panel
Google Search Console: flags poor CLS pages from CrUX data
Third-party tools like SpeedCurve, Calibre, and other RUM analytics services

These tools together help check, track, and improve layout stability across devices and users.

Compare CLS with LCP and FID

Cumulative Layout Shift (CLS) is one of the Core Web Vitals, along with Largest Contentful Paint (LCP) and First Input Delay (FID). Each of these metrics checks a different part of the user experience. CLS measures visual stability, LCP tracks loading speed, and FID (replaced by Interaction to Next Paint (INP) in 2024) checks interactivity.

Largest Contentful Paint (LCP)

LCP measures how fast the largest visible element (like a block of text or image) loads inside the viewport. A good LCP is 2.5 seconds or less. A page with slow LCP may feel blank or unfinished, which can lead users to leave early. LCP is reported in both lab tests (like Lighthouse) and field data (like CrUX). Improving LCP means speeding up server response, compressing images, and reducing blocking scripts.

First Input Delay (FID)

FID measures the time between the user’s first click or tap and the browser starting to respond. A good FID was 100 milliseconds or less. A poor FID could make the page feel laggy or unresponsive, especially if JavaScript blocked the main thread. Since FID needs real user interaction, it was only measured in the field.

In 2024, Google replaced FID with INP. INP checks many interactions, not just the first, and reports the worst delay. A good INP is 200 milliseconds or less. Like FID, INP reflects how responsive a site feels when people use it.

CLS tracks how often page elements move unexpectedly. If the layout shifts while the page is loading or during idle time, the score goes up. A good CLS is 0.1 or below. A high score means the page feels unstable. Users may click the wrong button, lose their place while reading, or get frustrated.

CLS is unique among the Core Web Vitals because it adds up multiple layout shifts into one score. It is measured in both lab and field settings. Tools use the Layout Instability API to track the movements. Developers can improve CLS by reserving space for images and ads, using CSS aspect ratios, and loading fonts early.

Summary table

Metric Name	What it checks	Good score	Why it matters	How it is measured
LCP (Largest Contentful Paint)	Checks how fast the main content (like big image or heading) loads	2.5 seconds or less	If LCP is slow, the page looks empty for longer. People may leave early.	In lab tests and from real users (field data)
FID (First Input Delay) (used till 2024)	Checks how fast the page reacts when user first taps or clicks	100 ms or less	If FID is high, the site feels stuck when people try to use it	Only from real users, not in lab tests
INP (Interaction to Next Paint) (used after 2024)	Checks the slowest delay when users interact with the page	200 ms or less	If INP is high, the page keeps lagging when people tap or scroll	Only from real users (field data)
CLS (Cumulative Layout Shift)	Checks how much the page jumps or shifts while loading	0.1 or less	If CLS is high, people may click wrong buttons or lose focus	Measured in both lab tools and real-user data

Each metric plays a different role in web performance. Pages that score well on all three provide a smoother and more reliable experience.

Compare CLS with other Core Web Vitals

Each Core Web Vital focuses on a different part of how users feel about a website. But these metrics often affect each other. For example, heavy JavaScript can slow down both loading and interaction. It may block the browser from showing content (hurting LCP), delay button clicks (hurting FID or INP), and trigger late layout updates (hurting CLS).

How users feel the difference

If LCP is poor, the page feels slow to show anything.
If FID or INP is poor, the page feels slow to respond when someone clicks or taps.
If CLS is high, the page feels jumpy, like things move around by themselves.

Each issue lowers trust and may push users away if the scores go beyond Google’s limits.

Different fixes for each metric

To fix LCP, speed up loading of large content like images and headings. Use CDNs, compress files, and remove blocking CSS or scripts.
To fix FID or INP, keep the main thread free. Break big tasks into smaller ones, defer non-essential scripts, and use web workers for heavy code.
To fix CLS, make sure layout stays steady. Always set image sizes, use CSS aspect ratios, and avoid putting new content above what’s already visible.

Challenges in fixing CLS on different websites

Reducing Cumulative Layout Shift (CLS) is not always simple. Some page types, layouts, and tools bring extra problems. Even when the final CLS score looks fine, users may still face smaller layout jumps that go unnoticed by the metric.

CLS in single-page apps and long sessions

Single-page applications (SPAs) often load content dynamically without full page reloads. Unlike traditional websites, CLS does not reset on every view. Instead, it tracks layout shifts in session windows. Only the worst 5-second window is counted. This means that if two moderate shifts happen at different times, they might both get ignored, even if the user felt both.

Developers working on SPAs should check CLS for each route or section, not just the total page. Some newer tools use soft navigation tracking, but until that becomes common, manual testing helps spot hidden issues.

Ads and third-party content

Advertisements and third-party embeds often cause layout shifts. These elements load late, resize on their own, or shift the content nearby. Since developers do not control the timing or size of ads, they must reserve space in advance using fixed CSS heights or aspect-ratio boxes.

Empty ad slots may leave gaps, so developers must balance revenue with layout stability. Some modern ad systems help by sharing size info early or loading in a progressive way. No matter the browser, if an element shifts on screen, it affects the user. So, visual care is needed on all platforms.

Mobile vs desktop differences

A layout that looks stable on desktop may shift on mobile if not checked properly. Screen size, font scaling, and layout flow change across devices. For example, a wide image with fixed width might work on desktop, but if it lacks defined height on mobile, it can cause a shift.

Tools like Lighthouse help simulate mobile layout. CrUX splits CLS by device type, which is useful for spotting platform-specific issues. Developers should test multiple breakpoints and use flexible CSS techniques that work across screens.

Challenges in frameworks and CMS tools

Some JavaScript frameworks (like React or Vue) had early problems with CLS. Client-side rendering could load extra components after the initial layout, pushing elements around. Solutions like server-side rendering, hydration matching, and skeleton placeholders help reduce this.

Even platforms like WordPress now add width and height attributes to images by default to lower CLS. Still, adding unoptimized plugins or widgets can reintroduce layout instability. Developers must test everything, including third-party code.

Reading and understanding the CLS score

The CLS score is a fraction, like 0.2 or 0.05. This makes it hard for some teams to know what actually shifted. A score like 0.2 means content moved and affected about 20 percent of the screen at some point.

To fix problems, tools like Chrome DevTools or Lighthouse show exactly which elements moved. These visual aids make debugging easier. Also, since only the worst 5-second shift window is counted, many small layout shifts may still go unnoticed.

Experts suggest aiming for zero visible shifts, not just staying under the 0.1 threshold. A good CLS score is helpful, but the real goal is smooth, steady pages. Every unexpected shift matters.

Conclusion

Cumulative Layout Shift (CLS) has become a core signal for judging visual stability on modern websites. It works with other Core Web Vitals like LCP and INP to give a full view of how users experience a page.

From 2024 to 2025, developers have focused more on fixing layout shifts by using design techniques that avoid sudden movements. This includes setting fixed sizes for images, reserving space for ads, and loading content in a controlled way.

Some challenges still exist, especially with dynamic content, single-page apps, and third-party embeds. But tools like Lighthouse, CrUX, and the Web Vitals library make it easier to detect and reduce layout problems.

A good CLS score helps show that a site feels steady and reliable. To maintain this, developers should plan for layout stability from the start. Even small, unexpected shifts can confuse users. Fixing them improves trust, usability, and overall page experience.

References

Category: SEO