5 Nov 25 
You go to tap a button and the page jumps, so you tap an ad instead. That is Cumulative Layout Shift, and it is both the most annoying Core Web Vital and one of the most fixable. Here is how.
You know this feeling even if you have never named it. A page is loading, you go to tap the link you want, and at the last instant the whole layout lurches down because an image or an ad finally loaded above it. Now you have tapped the wrong thing. That lurch is Cumulative Layout Shift, and of the three Core Web Vitals it is the one users feel as pure irritation. It is also, happily, one of the most fixable.
Here is what causes the jumps and how to stop them.
What CLS Actually Measures
CLS measures how much the visible content of your page moves around unexpectedly while it loads. A stable page that renders and stays put scores well. A page whose elements shove each other around as images, fonts, and ads arrive scores badly. The threshold and full definition live at web.dev/vitals, but the intuition is simple: every time something on screen jumps after the user can already see it, that is a shift, and shifts add up.
The reason it matters beyond annoyance is trust and misclicks. A page that moves under your finger feels broken and cheap, and it causes real accidental taps, which on a commercial page means frustrated visitors and sometimes wrong actions.
The Usual Culprits
Layout shift almost always comes from a small, familiar set of causes.
Images and video without dimensions. The most common one by far. If an image has no width and height reserved, the browser does not know how much space to leave, so it renders the text, then violently reflows everything when the image finally arrives. Reserve the space and the jump disappears.
Ads, embeds, and iframes. Anything injected into the page after load, an ad slot, a social embed, a widget, will shove content down when it appears unless a space was held for it. These are a frequent source of the worst shifts, and they tie directly to the third-party scripts that inject them.
Web fonts swapping in. When a custom font loads late and replaces the fallback, text can reflow as the new font’s spacing takes over, nudging everything around it.
Content inserted above what the user is reading. A cookie banner, a notification bar, or a “you may also like” block that pops in at the top pushes everything below it down at the worst possible moment.
How to Fix Each One
The fixes are mostly about one principle: reserve the space before the content arrives, so nothing has to move when it does.
For images and video, always give them explicit dimensions or an aspect-ratio box, so the browser leaves the right gap from the start and simply fills it. This single habit eliminates the majority of CLS problems we see.
For ads, embeds, and late-injected widgets, reserve a fixed slot of the correct size up front. If the slot is already the right shape, the content drops into it instead of shoving the page around.
For fonts, load them in a way that minimises the visible swap, so text does not dramatically reflow when the custom font arrives. Matching the fallback font’s metrics closely helps the swap go unnoticed.
For anything inserted dynamically, avoid placing it above content the user may already be reading. Put non-critical banners and blocks where their arrival will not push the main content, or reserve their space in advance.
Measure, Then Confirm on a Real Device
As with every vital, trust field data over a lab score, because CLS depends heavily on real loading conditions and real interaction, which a single lab run may not reproduce. And confirm your fixes the honest way: load the page on an actual phone over a normal connection and watch it settle. If nothing lurches as it loads, you have won. This is the same test-on-a-real-device discipline that catches the LCP and speed problems a desktop preview hides.
CLS is the rare performance problem that is both very annoying to users and genuinely straightforward to fix. Reserve space for everything that loads late, keep injected content out of the reading path, and the page stops fighting the person trying to use it.
If your pages jump around as they load and you want them made still, we fix this for a living.