Cumulative Layout Shift

Cumulative Layout Shift is the metric that measures how much your page jumps around as it loads. Think of it as the jarring moment you are about to click a link and an ad loads, shoving the content down, and you tap the wrong thing. That is a layout shift. CLS is one of Google's [Core Web Vitals](/core-web-vitals/), and it is the only one that has nothing to do with speed. It is about stability.

Google defines CLS as the sum of every unexpected shift's impact score, taken from the largest burst of shifts across the page's life. An impact score is calculated from the fraction of the viewport that moved and the distance it moved. The target is a score of 0.1 or less for at least 75% of visits. That is a hard target, but it is achievable if you are deliberate about how you load content.

I have seen sites drop their CLS from 0.8 to 0.05 by simply adding width and height attributes to images. That is the easiest win in all of technical SEO. The metric is not mysterious—it is a direct consequence of not reserving space for elements that load later. Ads, images, fonts, embeds, even dynamically injected cookie banners can all cause shifts. The fix is almost always the same: tell the browser how much space something will take before it gets there.

CLS matters most on mobile, where the viewport is small and every shift feels like a major disruption. On a [mobile SEO](/mobile-seo/) audit, I prioritise CLS above LCP because a slow page can still be navigated, but a jumpy page makes people leave. I have seen behavioural data from clients where a 0.3 CLS correlated with a 12% higher bounce rate on mobile. That is not a coincidence.

It also matters for pages with dynamic content. News sites, e-commerce product pages, and any page that loads third-party ads are the worst offenders. If you use [JavaScript SEO](/javascript-seo/) to inject content late, you need to reserve space with CSS aspect-ratio or a container with a fixed height. Otherwise, every API call becomes a potential shift.

Another place CLS bites is web fonts. A fallback font might render at a different size, and when the real font loads, the text jumps. I have seen this on content-heavy sites that use Google Fonts with no font-display strategy. The fix is to use font-display: swap or preload the font file. If you are on WordPress, plugins like [WordPress SEO](/wordpress-seo/) can help set these attributes, but you still need to check the theme's CSS.

Finally, CLS is a ranking signal, but not a strong one. Google has said it is a tiebreaker for equally relevant results. So if you have a site with good content but terrible CLS, you might lose to a competitor with slightly worse content but a stable page. I have seen this happen in competitive niches where the SERP is tight.

For years I thought CLS was mostly about images. I would add width and height to every <img> tag and call it done. Then I audited a news site that had perfect image attributes but still scored 0.35 on mobile. The culprit was a sticky header that appeared after the page loaded and pushed the entire content down. That shift is counted as unexpected because the user did not cause it. I had never considered that fixed-position elements that become sticky later can cause shifts.

I also assumed that CLS only mattered for the initial page load. Wrong. The metric measures shifts across the full lifecycle of the page, including after user interaction—as long as the shift is not directly caused by the user. So a lazy-loaded ad that appears when you scroll can still count. I now check for any element that appears after 5 seconds, especially if it is injected by a third-party script.

Another mistake was ignoring the impact of [pagination](/pagination/). On infinite scroll pages, loading the next set of results can shift the viewport if the new content is inserted above the current scroll position. I now advocate for pagination that loads new content below the fold, or at least reserves space for the next batch.

Finally, I used to rely solely on Lighthouse for CLS measurement. But Lighthouse is a lab tool with a fixed network and device. Real users on slow connections see much worse shifts because resources load in a different order. Now I always check the Chrome User Experience Report in Search Console, and I use the [SEO audit](/seo-audit/) feature to compare field data against lab data. The difference can be shocking.