CLS: how are layout shifts measured?
You go to tap Call now, a banner slides in, and you hit Close instead. CLS scores that kind of surprise.
Cumulative Layout Shift (CLS) is a score for a page's visual stability: it adds up unexpected movements of visible content during the worst burst of shifts in the page's life. Web.dev rates a CLS of 0.1 or less as good and anything above 0.25 as poor, at the 75th percentile of visits.
In short
- CLS has no unit: it is a score, not a time.
- Good is 0.1 or less; poor is above 0.25.
- Each shift scores impact fraction × distance fraction.
- Shifts within 500 ms of a tap, click or key press are excluded.
What does CLS capture?
Web.dev describes CLS as a measure of the largest burst of layout shift scores for every unexpected layout shift that happens during the lifetime of a page [1]. A shift happens when a visible element changes position from one frame to the next without the visitor asking for it.
Unlike LCP and INP, CLS is not measured in seconds or milliseconds. It is a unitless score, which tends to confuse people the first time they open a Core Web Vitals report [2].
How is a single layout shift scored?
Each shift gets a score equal to the impact fraction multiplied by the distance fraction. The impact fraction is the share of the viewport touched by unstable elements across two frames. The distance fraction is how far those elements moved, relative to the viewport's largest dimension [1].
What is a session window?
Shifts are grouped into session windows. A window collects shifts that happen less than one second apart and is capped at five seconds in total. The page's CLS is the total of the window with the highest score [1].
This keeps a long visit from piling up a huge score just because someone kept the page open while they called you.
Does every movement count?
| Situation | Counted? | Reason |
|---|---|---|
| An ad pushes the article text down while someone reads | Yes | Unexpected shift |
| Content moves within 500 ms of tapping Show more | No | Expected shift after a discrete input |
| Content moves while the visitor scrolls | Yes | Scrolling does not exclude shifts |
| A late image without set dimensions pushes the Book button down | Yes | Element moved without visitor action |
Only discrete inputs such as taps, clicks and key presses exclude shifts in the following 500 ms; scrolls, drags and pinch-zoom do not [1].
What usually causes a poor CLS?
- Images with no width and height set, so text jumps when they arrive.
- Cookie or promo banners that push the page down instead of overlaying it.
- Third-party review or map widgets that grow after the page has rendered.
- A phone button placed right under an area that changes size.
- Only testing on a wide desktop screen, where shifts look smaller than on a phone.
Does Pilotiko check CLS?
Pilotiko does not advertise CLS measurement. Its available visibility features focus on search engine optimization for the site it hosts: structured data, a sitemap, robots.txt and llms.txt, plus an audit of your current site.
Frequently asked questions
What is a good CLS score?
Web.dev considers 0.1 or less good. Above 0.25 is poor, and anything in between needs improvement.
Why does CLS have no unit?
Because it multiplies two fractions: how much of the screen was affected and how far things moved relative to the screen size. The result is a score, not a duration.
Do cookie banners hurt CLS?
Only if they move existing content. A banner that overlays the page without pushing it does not create a layout shift.
Does opening a menu after a tap raise CLS?
Not if the movement happens within 500 milliseconds of the tap. Web.dev excludes those shifts because the visitor expected them.
Is CLS measured for the whole visit?
Yes, but only the session window with the highest score is kept, and windows last at most five seconds. A long visit is not penalized just for being long.
What is the quickest CLS fix?
Give every image explicit dimensions and reserve space for banners and embedded widgets. Both changes are simple and worth trying before any redesign.
Sources
- web.dev (Google), Cumulative Layout Shift (CLS) (accessed on October 15, 2026).
- web.dev (Google), Web Vitals (accessed on October 15, 2026).
- Google Search Central, Understanding Core Web Vitals and Google search results (accessed on October 15, 2026).
Read next
Core Web Vitals: what do Google's page experience metrics measure?
Core Web Vitals explained: Google's three page experience metrics, the official good and poor thresholds, a worked example for a service business.
LCP: what does Largest Contentful Paint measure?
Largest Contentful Paint explained: what counts as the LCP element, the 2.5-second target, a worked image example and the mistakes small sites make.
INP: how is page responsiveness measured?
Interaction to Next Paint explained: which taps and clicks count, the 200 ms target, how it replaced FID and a booking form example for a service business.