CLS Above Target, When the Page Shifts Under Your Cursor
CLS above target. That is the flag when a page’s Cumulative Layout Shift passes 0.1, and CLS measures how much the visible layout moves after it first appears. It is one of the three Core Web Vitals, and it captures a specific failure, a page that keeps rearranging itself while the visitor tries to read it or click on it.
The numbers in real reports get severe fast. One recent report in our records shows a page at 0.669 on desktop and 0.308 on mobile, against the 0.1 target, costing ten points on the desktop performance score and twelve on mobile. That is a page where content is visibly jumping around, which is not a cosmetic quirk, it is the kind of instability that makes a site feel broken and pushes visitors away.
What CLS measures
Layout shift happens when visible content moves after the page has started to render. An image loads and pushes the text below it down, an ad slot appears and shoves the article aside, a font swaps in and changes the size of a heading, a cookie banner slides in from the bottom. CLS scores each shift by how much of the viewport moved and how far it moved, and adds the score across the life of the page.
The target is 0.1, and past 0.25 the finding escalates, because at that level the page is shifting so much that it interferes with reading and clicking. The measurement window matters too, CLS counts shifts the whole time the page is open, not just during loading, which is why a banner that slides in after the visitor has started reading can still push the score over target.
There is an important exception, and it protects the shifts you want. Layout changes that happen within half a second of a visitor interaction, like opening an accordion, expanding a menu, or submitting a form, are treated as expected responses to that input and do not count against CLS. The metric is measuring unexpected movement, not punishing intentional changes, so a page that expands a section when tapped is not penalised for doing what the visitor asked.
The click that lands somewhere else
The harm of layout shift is not visual, it is physical. A visitor moves their cursor to tap a button, and the page shifts a moment before the tap lands, so the click hits whatever moved into that spot instead. On a news page that might mean opening the wrong article, on a shop page it can mean adding the wrong item, and on a form it can mean submitting the wrong field or losing what was typed.
That is why CLS matters more than the other metrics to the feel of a page. A slow page asks the visitor to wait, which is frustrating, but a shifting page asks them to chase the content, which is worse. The most damaging shifts happen late, after the visitor has committed to reading or interacting, which is also why the worst offenders are often late-loading elements, ads, embeds, and consent banners.
Reserving space before it loads
The core fix is to reserve space for everything that will load, before it loads. An image that knows its dimensions can be given that space in the layout, so when it arrives nothing moves. The simplest way is an explicit width and height on the image tag, which modern browsers use to calculate the image’s aspect ratio automatically, so the browser reserves the right shape from the start and nothing shifts when the file lands.
<img src="/images/article-photo.webp" width="1600" height="900">
<div style="aspect-ratio: 16 / 9">...</div>
For images, the width and height attributes alone are enough, because the browser derives the aspect ratio from them and holds the space open. The explicit aspect-ratio style matters for elements that do not have intrinsic dimensions, like a video embed or a dynamic container, where the browser has no way to guess the shape, so it has to be told.
The same principle covers the other usual suspects. Reserve a fixed space for ad slots instead of letting them expand into the content, and give embeds and videos an explicit height. Fonts need a careful choice, font-display swap shows text in a fallback font and then swaps it when the real font arrives, which avoids invisible text but can shift the layout if the two fonts have different metrics. The safer option for zero shift is font-display optional, which uses the fallback and only swaps in the real font if it is ready in time, and when swap is required, the font’s metrics should be matched to the fallback so the swap does not move the text.
If your site runs WordPress and you never touch theme files, a good part of this is already done for you. Images you add through the editor carry their width and height automatically, WordPress writes both into the image tag, which is why ordinary uploaded photos rarely shift. The shifts on a typical WordPress site come from elements the theme or a plugin inserts late, and the owner-level fix is usually a setting on whichever plugin adds the element, or a theme update, since layout fixes ship in updates. Fonts are the one part that lives in the theme’s own code, so if text jumps when the page settles, check the theme’s font settings first, and if there is no such setting, hand that one to the person who maintains the theme together with this section of the guide.
Stopping content that arrives late
Reserving space fixes elements that load in a known place, but some shifts come from content that should not be there at all until the visitor asks for it. A chat widget that pops in, a newsletter box that slides up after a delay, a consent banner that appears over the page, all of these shift the layout when they arrive. The fix is either to reserve their space from the start or to load them so they overlay content instead of pushing it, and on a WordPress site these late arrivals are usually plugins, whose own settings often hold the choice between pushing the page down and floating over it.
The classic pattern is content inserted above existing content after load, a banner at the top of the page that pushes the article down the moment the visitor starts reading. Whatever the element, the test is the same, does anything change position after the page first paints. If it does, the change needs to happen in reserved space or not at all.
Watching the layout settle
Re-test after each change, because CLS drops fast when the cause is real. The report gives the measured value every run, so you can watch it fall toward the 0.1 line and past it. The element that causes the shift is usually visible in the browser developer tools too, which highlight what moved and when, making this one of the easier metrics to diagnose.
One honest note on how common this is. Most tested sites pass CLS, our own benchmarks on the global analytics page show the average Cumulative Layout Shift at 0.078 on desktop and 0.039 on mobile, both under the 0.1 target, and even the slowest ten percent of pages sit at 0.186 on desktop and 0.087 on mobile, with only the desktop tail crossing into failing territory. That makes a CLS flag worth taking seriously, because a page that fails it is in the worse minority, and the fix is usually a handful of elements that were never told how much space they would take.
