Cumulative Layout Shift (CLS) diagnosis
Cumulative Layout Shift (CLS) measures visual stability — how much page content unexpectedly moves while loading. It is one of the three Core Web Vitals. A good CLS is 0.1 or less; the usual causes are images and ads without reserved space, late-loading fonts, and content injected above existing elements. This page explains the metric, its thresholds, and the diagnosis-and-fix workflow.
What CLS measures
CLS quantifies unexpected layout shifts — visible elements changing position from one rendered frame to the next without user interaction. Each shift's score combines how much of the viewport moved (impact) and how far it moved (distance). CLS sums the largest burst of shifts during the page's lifespan.
Thresholds: a good CLS is 0.1 or less at the 75th percentile; 0.1 to 0.25 needs improvement; above 0.25 is poor. Shifts within 500ms of a user interaction are excluded, because expected, user-initiated movement is not penalized.
- Measures unexpected visual movement during load
- Good: ≤ 0.1; Needs improvement: 0.1–0.25; Poor: > 0.25
- Scored on impact (viewport area) × distance moved
- User-initiated shifts within 500ms are excluded
Common causes
The frequent culprits are images and video without explicit width/height (or aspect-ratio), ad and embed slots that have no reserved space and push content when they load, web fonts that cause a flash of unstyled/swapped text, and dynamically injected content (banners, notices) inserted above existing content.
To diagnose, reproduce the load and watch what jumps, or use Lighthouse/PageSpeed which highlights the elements contributing most to CLS. Field data tells you whether real users actually experience the instability.
Fixing CLS
Always set explicit dimensions or an aspect-ratio on images, videos, iframes, and ad slots so the browser reserves space before the resource loads. Reserve space for dynamic content rather than inserting it above existing elements.
Preload key fonts and use font-display strategies that avoid large metric swaps, and apply transforms instead of properties that trigger layout for animations. Re-measure with field data; CLS often improves dramatically once dimensions are reserved.
How it appears in analytics and logs
A poor CLS means content shifts unexpectedly during load, often causing mis-clicks. Like other Core Web Vitals, it is a page experience ranking input and not a crawl or index gate. A high CLS does not prevent crawling; it is a UX and ranking-refinement issue.
Diagnostic use case
Find and eliminate unexpected layout jumps that frustrate users and trigger a poor CLS, distinguishing real visual instability from cosmetic concerns.
What WebmasterID can help detect
CLS is a client-side rendering metric outside WebmasterID's crawl-side scope. WebmasterID helps you first confirm a page is crawled and indexed; layout-stability work is then done with field and lab vitals tooling.
Common mistakes
- Serving images, ads, or embeds without reserved dimensions or aspect-ratio.
- Injecting banners or notices above existing content after load.
- Treating CLS as a crawl/index blocker rather than a UX and ranking input.
- Fixing lab CLS while ignoring the field (CrUX) value Google uses.
Privacy and accuracy notes
Field CLS is aggregated from anonymized real users via CrUX. WebmasterID does not record per-user layout behavior or fingerprint visitors; it observes only crawler fetches and responses.
Frequently asked questions
- What is a good CLS score?
- 0.1 or less at the 75th percentile of page loads. Between 0.1 and 0.25 needs improvement, and above 0.25 is poor.
- What most commonly causes layout shift?
- Images, ads, and embeds without reserved space, late-loading web fonts, and content injected above existing elements. Reserving dimensions for media and dynamic slots fixes most CLS.
Related pages
- Core Web Vitals and crawling
Core Web Vitals are Google's three user-centric performance metrics — Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. They are a page experience signal used in ranking, but they do not gate crawling or indexing: a slow page can still be crawled and indexed. This page explains how vitals are measured in the field versus the lab and where they fit in the crawl-to-rank pipeline.
- Largest Contentful Paint (LCP) diagnosis
Largest Contentful Paint (LCP) measures when the largest content element in the viewport finishes rendering — a proxy for how quickly the main content becomes visible. It is one of the three Core Web Vitals. A good LCP is 2.5 seconds or less; the most common culprits are slow server response, render-blocking resources, slow resource load, and client-side rendering delays. This page breaks down the metric and its diagnosis.
- Interaction to Next Paint (INP) diagnosis
Interaction to Next Paint (INP) measures overall page responsiveness by observing the latency of user interactions throughout a visit and reporting a representative worst case. It became a Core Web Vital in March 2024, replacing First Input Delay. A good INP is 200ms or less; long tasks and heavy JavaScript on the main thread are the usual causes. This page covers the metric and its diagnosis.
- Website observability
Confirm a page is crawled and indexable before refining its vitals.
Sources and verification notes
- web.dev — Cumulative Layout Shift (CLS)Definition, scoring (impact × distance), and thresholds.
- web.dev — Optimize CLS
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.