Cumulative Layout Shift (CLS) is a Core Web Vitals metric that scores how much visible page content moves unexpectedly during load. It's calculated as the largest 5-second window of layout shifts that were not caused by user interaction. Google's thresholds: Good ≤ 0.1, Needs Improvement 0.1-0.25, Poor > 0.25.
CLS is the number that tells you whether your page respects the reader's eyes and thumbs. A single mis-tapped ad can be worth more traffic loss than a slow backend — and Google now scores you on it directly.
What is CLS as a metric?
CLS is the third of Google's Core Web Vitals, tracking visual stability. Every unexpected movement of a visible element between two rendered frames counts as a layout shift. CLS sums those shifts across the worst 5-second session window on the page.
Where the other two Core Web Vitals live:
- LCP (Largest Contentful Paint) — how fast the main content paints. Target < 2.5s.
- INP (Interaction to Next Paint) — how quickly the page responds to input. Target < 200ms.
- CLS (Cumulative Layout Shift) — how stable the page stays while loading. Target < 0.1.
Good: ≤ 0.1. Needs Improvement: 0.1 to 0.25. Poor: > 0.25. To pass Core Web Vitals overall, at least 75% of your page loads (real-user field data) must fall in the Good bucket.
Why the CLS metric matters
The metric matters because Google uses it to gate page experience, and because it's tied directly to conversion and retention.
- Direct SEO impact. Pages failing CLS thresholds lose the page experience signal that lifts near-neighbor pages in tight-margin queries.
- Conversion loss. Ecommerce sites with poor CLS see 10-15% conversion drops. Every mis-tap is a lost sale.
- Bounce increases. News and content sites report 20% higher bounce on pages with CLS above 0.25.
- 3x abandonment on high CLS. Users are 3x more likely to leave when the page misbehaves visually.
- It compounds over time. The engineering discipline that fixes CLS also raises LCP and INP — Core Web Vitals move together.
How CLS scoring actually works
Each layout shift score is calculated as:
Shift score = Impact Fraction x Distance Fraction
# Impact Fraction: % of viewport affected by the shift
# Distance Fraction: how far elements moved (as % of viewport)
# Page CLS = sum of shifts in the largest 5s session window
# User-initiated shifts (within 500ms of input) are excluded
The 5-second session window means that isolated shifts don't accumulate forever. Only the worst contiguous burst is scored. That matters because a single stubborn cookie banner during load can drive an entire page's CLS above threshold on its own.
Where CLS problems typically come from
| Cause | Signal in DevTools | Fix |
|---|---|---|
| Missing image dimensions | Layout Shift on img element | Set width + height or aspect-ratio |
| Ad injection | Shift correlates with ad script load | Reserve min-height slot |
| Web font swap (FOUT) | Text reflow after font-face load | Preload font, match metrics |
| Dynamic banners | Push-down of viewport content | Overlay instead of push |
| Third-party embeds | iframe load causes shift | Wrap in aspect-ratio container |
| Skeleton mismatch | Placeholder size ≠ final content | Match skeleton dimensions to real content |
Real CLS fixes in code
1. Aspect-ratio CSS for responsive images
img {
aspect-ratio: attr(width) / attr(height);
height: auto;
width: 100%;
}
2. Cookie banner overlay (not push-down)
.cookie-banner {
position: fixed;
bottom: 0;
left: 0;
right: 0;
z-index: 1000;
}
3. Font preload + match metrics
/* Match fallback metrics to reduce swap shift */
@font-face {
font-family: 'Inter';
src: url('/font.woff2') format('woff2');
font-display: optional;
}
CLS metric vs the other Core Web Vitals
CLS covers
- Visual stability during load
- Element movement not caused by user input
- Largest 5-second session window
- Fixed by reserving space + overlay patterns
- Target: 0.1 or less
LCP and INP cover
- LCP: loading of the largest visible element (< 2.5s)
- INP: input responsiveness across the visit (< 200ms)
- All three together = page experience
- Measured over 75th percentile of real users
- Need to pass all three for a Good rating
7 best practices for the CLS metric
- Ship width and height on every image. Non-negotiable. Applies to responsive images too via aspect-ratio.
- Overlay, don't push. Cookie banners, promo bars, chat widgets — all overlay, never push viewport content.
- Reserve fixed slots for ads and embeds. Min-height that matches the final content.
- Preload critical fonts with matched metrics. Prevent FOUT-driven text reflow.
- Match skeleton screens to final dimensions. Placeholder size = real content size.
- Measure field data, not lab. Lab CLS routinely misses ads, chat widgets, and user-specific injections.
- Audit per template. Fix CLS at template level (blog, product, category) instead of URL by URL.
CLS regresses fast. A new ad partner, a font swap, a marketing widget added by the growth team — any of them can push a passing page into the Poor bucket overnight. Monitor CLS in Search Console monthly, not annually.
Common CLS mistakes to avoid
- Optimizing lab-only. Field data is what ranks. Lab is only for debugging.
- Skipping mobile. Mobile CLS is usually worse than desktop and mobile is what Google ranks on.
- Fixing shifts caused by user input. Those don't count — user-triggered layout changes are excluded.
- Ignoring third-party widgets. The biggest CLS culprit on most sites lives in JS you don't own.
- Aiming for CLS = 0. Under 0.1 is Good. Perfection is a poor use of engineering time.
How theStacc helps with the CLS metric
CLS is a template problem, so fix it at the template level and every article inherits the fix. theStacc publishes into your existing CMS templates rather than injecting its own layout, which means the articles it ships carry whatever layout stability you have already built — and its SEO score flags on-page issues with suggestions you can hand to engineering.
Frequently asked questions
CLS stands for Cumulative Layout Shift. It's one of the three Core Web Vitals — the metrics Google uses to score page experience — alongside LCP (loading) and INP (interactivity).
0.1 or less is Good. Between 0.1 and 0.25 is Needs Improvement. Above 0.25 is Poor. Google's target is CLS under 0.1 for at least 75% of page loads, measured in real-user field data.
CLS is part of Google's page experience ranking signal. Pages that fail CLS thresholds compete at a disadvantage against faster peers. High CLS also correlates with 10-15% conversion drops on ecommerce and 20% higher bounce on news sites.
Use PageSpeed Insights and Google Search Console for real-user field data. Use Chrome DevTools Performance panel and Lighthouse for lab-based debugging. Field data is what Google ranks on; lab data is for reproducing and fixing.
Yes. CLS is one of the three Core Web Vitals Google publishes benchmarks for and has kept in the ranking signal since 2021. The threshold has not changed and continues to gate page experience scoring.
Related glossary terms
Sources
