Cumulative Layout Shift: 8 Fixes That Actually Work
Cumulative layout shift is what happens when a page rearranges itself while you're reading it. A button moves. An image pushes the text down. You tap the wrong link. It's one of Google's three Core Web Vitals, and a poor score does real damage, both to how the site feels and where it ranks. Most of the causes are fixable. They just take a bit of digging to find.
On this page
- 1. Set Width and Height on Every Image
- 2. Reserve Space for Ads and Embeds
- 3. Preload Your Key Fonts
- 4. Use font-display, swap Carefully
- 5. Avoid Inserting Content Above Existing Content
- 6. Watch Out for Animations That Affect Layout
- 7. Test With Real Field Data, Not Just Lab Tools
- 8. Check Lazy-Loaded Images Below the Fold
1. Set Width and Height on Every Image
This is the most common cause of a bad CLS score. When a browser loads a page and encounters an image with no declared dimensions, it has no idea how much space to reserve. So it collapses the space to nothing, loads the content around it, then shunts everything down when the image finally arrives.
The fix is straightforward. Add width and height attributes to every <img> tag in your HTML. WordPress now does this automatically for images inserted through the block editor, but older themes and custom code often miss it. Check your image handling in WordPress if you’re unsure whether your setup is covering this properly.
2. Reserve Space for Ads and Embeds
Adverts are one of the worst offenders. They load late, they vary in size, and they push content around without warning. The same goes for embedded videos, third-party widgets, and social media blocks.
Give these elements a fixed container. Set a minimum height on the wrapper div so the space exists before the content loads. It won’t look perfect every time, but it stops the page lurching around for the person reading it.
3. Preload Your Key Fonts
When a custom font loads late, the browser substitutes a fallback font first. Then, once the real font arrives, it swaps it in. If the two fonts are different sizes, everything on the page shifts.
Preloading the font tells the browser to fetch it early, before it’s needed. Add a <link rel="preload"> tag in the <head> of your page for any font files the design depends on. It’s a small change that removes a surprisingly common source of layout shift.
4. Use font-display, swap Carefully
There’s a trade-off here worth being honest about. font-display, swap is widely recommended because it stops invisible text while fonts load. But it can actually increase cumulative layout shift if the fallback font and the web font render at very different sizes.
The better approach is to also use size-adjust, ascent-override, and descent-override on your fallback font face. These CSS descriptors let you make the fallback closer in size to the real font, so the swap causes less movement. It’s fiddly, but it’s the proper fix.
5. Avoid Inserting Content Above Existing Content
Cookie banners, notification bars, and pop-ups that load after the page renders are a straightforward cause of layout shift. If something appears above the fold and pushes everything else down, that registers as CLS.
Either render these elements server-side so they exist from the first paint, or position them as overlays that don’t affect document flow. A banner that slides in from the bottom causes far less shift than one that pushes the header down.
6. Watch Out for Animations That Affect Layout
CSS animations are fine when they use properties like transform and opacity. These run on the GPU and don’t trigger a layout recalculation. The problem comes when animations change width, height, top, left, or margin. Those properties force the browser to recalculate the whole layout, and that shows up as shift.
Go through any entrance animations or hover effects on the site. If they’re moving elements by changing positional properties rather than using transform, translate(), they’re costing you CLS.
7. Test With Real Field Data, Not Just Lab Tools
PageSpeed Insights gives you a lab score, which is useful. But Google measures CLS using real user data collected in Chrome, published through the Chrome UX Report. The two scores can look quite different.
A page might score well in the lab because the test loads everything instantly on a fast connection. Real users on slower devices, with ad blockers off and third-party scripts firing, often see much worse shift. If your Search Console is showing a CLS issue that your lab score doesn’t reflect, trust the field data. That’s what Google is actually using to rank the page.
8. Check Lazy-Loaded Images Below the Fold
Lazy loading is good practice. But if it’s applied to images that are close to the viewport on mobile, the browser may load the page, begin rendering visible content, and then shift things around as those near-viewport images arrive. The practical Core Web Vitals fixes for this involve adjusting the lazy-load threshold so images a little further down the page are fetched sooner, before they enter the viewport.
It’s worth auditing which images on each page template actually need lazy loading and which are close enough to the fold that eager loading makes more sense.