You are about to tap a button on your phone when the page moves. The button is no longer under your finger. That shift has a measure: CLS. In a lab test of my website on 7 September 2026, using mobile emulation, the result was 0.262. That put it in the range Google classifies as poor.
CLS stands for Cumulative Layout Shift. It measures unexpected changes in the position of visible content, not how long the site takes to load. A score of 0.1 or less is good; above 0.1 and up to 0.25 needs improvement; above 0.25 is poor. Google explains the metric and its thresholds.
The problem was in the placeholder
I looked for the element that changed position. The footer moved from pixel 593 to pixel 15,350. It initially appeared within the first screen, then ended up much further down. The problem was not limited to mobile either.
The cause was a replacement during the page's startup. The browser showed a placeholder before rendering the full content. That placeholder reserved just 60% of the screen height, leaving the footer visible. When the rest appeared, the footer moved out of view.
I reserved a full screen height. The footer stayed outside the first screen both during the placeholder and afterwards. It could still change position, but that movement was no longer visible and did not count towards CLS. In a local comparison of the two versions under the same test conditions, the mobile result went from 0.262 to 0.
| Local comparison with mobile emulation | Before | After |
|---|---|---|
| CLS | 0.262 | 0 |
| Footer during the placeholder | Pixel 593, within the first screen | Pixel 918, outside the first screen |
| Space reserved for the placeholder | 60% of the screen height | A full screen height |
That zero belongs to the local test. It does not establish the current result of the published website.
I opened that website every day and had not noticed it. The problem was in a placeholder that disappeared within a few tenths of a second.
How to read the PageSpeed result
To check your site, go to PageSpeed Insights, enter its address and select mobile. Look for CLS, but also note where it appears.
The user experience section covers real visits over the last 28 days, if enough data is available. Check whether it refers to that page or the whole site. The lab test simulates a page load and helps investigate the problem. It may miss shifts that happen later during a visit. PageSpeed's documentation distinguishes the two readings.
If you have just fixed something, that test may show the improvement before the visit history does. And if real visit data is missing, that evidence is missing: it does not mean everything is fine.
A high CLS does not identify the cause by itself either. On another site, an image, a font or an element appearing later may be involved. I would ask whoever maintains the page to locate what moves and what pushes it before changing anything.
A measure of behaviour
CLS does not tell me whether the text makes sense or whether the site generates sales. I have no measurement of sales lost because of that shift. I cannot turn an improvement from 0.262 to 0 into a revenue promise.
If you see a poor score, save the address, the date and whether it comes from real visits or a test. Ask to be shown the shift before the fix and to have the test repeated afterwards.
Sources
- Google/web.dev: CLS definition, thresholds and measurement limits — Accessed on 10-10-2026.
- Google: interpreting PageSpeed Insights data — Accessed on 10-10-2026.
- My own CLS measurements — Record dated 7 September 2026. Lighthouse with mobile and desktop emulation and observation of positions during loading. Controlled comparison in a local preview: mobile 0.262 → 0. It does not establish the current value of the published website.
If you want to tell me about a shift you have found, you can write to hola@hebra.studio. The address and a screenshot of the result are a useful starting point.