CLS (Cumulative Layout Shift) is the Core Web Vitals metric for visual stability: it quantifies how much visible content moves unexpectedly while a page is open. In web performance practice, CLS sits beside LCP, which measures loading, and INP, which measures responsiveness, and it is the only one of the three that has no time unit. A good score is 0.1 or less at the 75th percentile of real page views.
The metric exists because unexpected movement damages usability in ways that loading speed alone does not reveal. A button that jumps just before a tap, a paragraph that slides down while someone reads, or an advertisement that pushes a form out of view all produce layout shifts that CLS records.
How CLS scores a layout shift
A layout shift occurs when a visible element changes its start position between two rendered frames. The browser does not count elements that merely grow in place, elements that are newly inserted without displacing others, or movement driven by CSS transform. It counts only unstable elements whose top-left position in the viewport changes.
Each individual shift receives a layout shift score equal to the impact fraction multiplied by the distance fraction. The impact fraction is the share of the viewport covered by the union of the unstable elements in the previous and current frames. The distance fraction is the largest movement of any unstable element divided by the larger viewport dimension.
The following table shows how the two fractions combine in typical situations on a viewport 800 pixels tall.
| Situation | Impact fraction | Distance fraction | Shift score |
|---|---|---|---|
| Banner pushes article down 200 px | 0.75 | 0.25 | 0.19 |
| Image without size loads above text | 0.50 | 0.30 | 0.15 |
| Web font swap reflows a heading | 0.10 | 0.02 | 0.002 |
| Cookie notice slides in at bottom | 0.15 | 0.05 | 0.0075 |
Session windows and the 500 ms input exclusion
CLS is not a simple sum over the whole page lifetime. Since 2021 the metric groups shifts into session windows: a window collects shifts that occur less than 1 second apart, and it closes after a maximum of 5 seconds. The reported CLS is the largest session window, which keeps long-lived single-page applications from accumulating unbounded scores.
Shifts that occur within 500 milliseconds of a discrete user input, such as a click, a tap or a key press, are flagged with hadRecentInput and excluded. The reasoning is that the user caused the change and expects it. Scrolling and pointer movement do not count as such input, so content that jumps during a scroll still counts.
The thresholds below are applied to the 75th percentile of page views, segmented by mobile and desktop.
| Rating | CLS value | Typical user perception |
|---|---|---|
| Good | 0.1 or less | Page feels stable |
| Needs improvement | Above 0.1 up to 0.25 | Occasional noticeable jumps |
| Poor | Above 0.25 | Frequent misclicks and lost reading position |
CLS compared with LCP, INP and FCP
CLS measures a different quality dimension from its neighbors in web performance. Loading metrics answer when something appears, responsiveness metrics answer how fast the page reacts, and CLS answers whether what appeared stays where it is. A page can load quickly and still score poorly on CLS.
| Metric | What it measures | Unit | Good threshold |
|---|---|---|---|
| CLS | Unexpected visual movement | Unitless score | 0.1 or less |
| LCP | Render time of largest content element | Seconds | 2.5 s or less |
| INP | Latency from interaction to next paint | Milliseconds | 200 ms or less |
| FCP | Time to first rendered content | Seconds | 1.8 s or less |
Optimizations sometimes pull these metrics in opposite directions. Lazy loading images without reserved space can improve LCP but worsen CLS, and an aggressive font-display swap improves FCP while introducing small text reflows. Balanced tuning reviews all three Core Web Vitals together.
Common causes and fixes for layout instability
Most layout shifts come from content whose size is unknown at first render. The browser lays out the page with the information it has, then must move content when the real dimensions arrive. The fix is almost always to reserve space in advance or to insert content where it cannot displace anything.
| Cause | Symptom | Recommended fix |
|---|---|---|
| Images without dimensions | Text jumps when image loads | Set width and height or aspect-ratio |
| Ads and embeds | Slot expands after auction | Reserve a minimum slot height |
| Injected banners | Content pushed down at top | Overlay or reserve space |
| Web font swap | Lines rewrap after font loads | Use size-adjust and preload fonts |
| Layout-property animation | Neighbors move every frame | Animate transform and opacity |
| Late client-side rendering | Skeleton replaced with taller content | Match skeleton size to final content |
Modern browsers derive an intrinsic aspect ratio from the width and height attributes of an image, so supplying them is enough even for responsive images. For dynamic content such as recommendations, a fixed-height container with internal scrolling or a placeholder sized to the most common result removes the shift entirely.
Measuring CLS in the lab and in the field
Field data reflects real users and is the basis of the Core Web Vitals assessment. Browsers expose shifts through the PerformanceObserver interface with the layout-shift entry type, and monitoring scripts compute session windows from those entries. Aggregated public datasets report the 75th percentile over a rolling 28-day period.
Lab data from tools such as Lighthouse captures only the shifts that occur during an automated page load without scrolling or interaction. Lab CLS is therefore often lower than field CLS, because many shifts happen after the initial load, when users scroll into lazy-loaded sections or open interactive widgets.
- Lab tools are best for reproducing and debugging a known shift.
- Field monitoring shows which templates and devices produce the real problem.
- Attribution data in layout-shift entries names the sources, which shortens diagnosis considerably.
Pitfalls and misconceptions
A frequent mistake is to treat CLS as a loading-only metric. Shifts caused by infinite scroll, late consent dialogs or accordion widgets after the first second all count, so a page that looks stable in a quick test can still fail in the field. Another misconception is that any movement is penalized; animations built with transform and changes made right after user input are excluded by design.
Teams also misread small scores. A value of 0.05 is already good, and chasing zero rarely changes user experience. The useful priority is the largest session window on high-traffic templates, because that is what determines the reported score.
The idea in brief
CLS measures how much a web page jumps around while you look at it. Imagine reading a newspaper while someone keeps sliding new pictures in above your line. You lose your place, and you might tap the wrong thing.
The score is a small number. Below 0.1 means the page feels steady, and above 0.25 means it moves enough to annoy people. Developers fix it mostly by saving space for things before they arrive, such as images and advertisements.
A practical scenario
A regional news site sees many readers abandon articles on mobile phones. Field monitoring reports a CLS of 0.31 on article pages. Attribution data shows two sources: hero images loaded without width and height attributes, and an advertisement slot between paragraphs that grows from zero to 250 pixels after the ad auction finishes.
The front-end team adds explicit dimensions to every article image and gives the ad container a reserved minimum height of 250 pixels, showing a neutral placeholder when no ad is served. They also preload the headline font and apply size-adjust to the fallback font to keep line breaks identical.
After the next 28-day collection period, the 75th percentile CLS on mobile falls to about 0.04. Accidental taps on advertisements drop, and readers no longer lose their position when the page finishes loading.