How to Fix Cumulative Layout Shift (CLS) on WordPress

On this page

1. How CLS is scored
2. Find what's shifting
3. Images, videos and embeds without reserved space
4. Ads and content added after loading
5. Web fonts
6. Banners, cookie notices and offer bars
7. Sticky and shrinking headers
8. Confirm the fix

Cumulative Layout Shift (CLS) measures how much visible content moves unexpectedly on a page. You start reading, an image loads above the text and everything jumps down. You go to tap "Call now" and hit a banner that has just appeared. Here's how to find and fix the usual causes on WordPress. For how CLS fits alongside LCP and INP, see Core Web Vitals explained.

How CLS is scored

CLS score	Google's rating
0.1 or less	Good
Between 0.1 and 0.25	Needs improvement
More than 0.25	Poor

CLS isn't a time. Each shift is scored by how much of the screen was affected and how far things moved. Shifts close together are grouped, and your CLS is the worst group during the visit. Two details explain most confusion:

• Expected shifts don't count. Changes within about half a second of a tap, click or key press are ignored, like an accordion opening. Scrolling doesn't count as that kind of input.
• The whole visit counts. Shifts while someone scrolls, from lazy-loaded images or a header changing size, are included.

So a page can pass a lab test but fail in Search Console: lab tools mostly measure the first load, while field data comes from real visitors who scroll, wait and tap.

Find what's shifting

1. In Search Console's Core Web Vitals report, open the CLS issue to see example URLs. Similar pages are grouped, so fixing a shared template often fixes many pages.
2. Run an example page through PageSpeed Insights on mobile. The diagnostics list the elements involved in the largest shifts.
3. Open the page on your phone using mobile data, then scroll to the bottom and back. Slower connections make late-arriving content easier to spot.
4. In Chrome DevTools, the Rendering panel can highlight layout shift regions as they happen, and a Performance panel recording lists each shift and the elements that moved.

Usually the culprit is something above the moved element that appeared late or changed size.

Images, videos and embeds without reserved space

This is the most common cause. If the browser doesn't know how big something will be, it gives it no space, then pushes everything down when it arrives.

• Images: WordPress adds width and height to images inserted into posts, but theme templates, page builder widgets, custom HTML and some plugins can miss them. Check the page source for image tags without width and height, and add them; with height: auto in the CSS, images still scale on phones. See image optimisation for WordPress.
• Lazy-loaded images: fine when dimensions are set. Without them, each image shifts the page as the visitor scrolls.
• Videos: give YouTube and other video containers a fixed aspect ratio, such as 16:9, so the space exists before the player loads.
• Maps, social feeds, review and booking widgets: these load from other servers, often last. Give their containers a minimum height close to their final size. For maps, see adding Google Maps without slowing your site.
• Sliders: before the slider's script runs, slides can appear stacked, then collapse. Set a fixed height for the slider area, or use a single image instead.

Ads and content added after loading

Ad sizes often aren't known in advance. If your site shows ads:

• Reserve space for each slot with a minimum height matching the ad size usually served there
• Avoid slots at the very top of the content, where a late ad pushes the most content down
• Test pages after switching on automatic ad placement, which inserts ads wherever it chooses
• Keep an empty slot's space rather than collapsing it after loading

The same applies to anything JavaScript adds later, such as related products, review carousels or notices: reserve space for it, or add it below what the visitor is looking at.

Web fonts

When a custom font arrives after the text has appeared, the text swaps from a fallback font to the web font. If the two differ in size, lines rewrap and everything below moves.

• Use one or two font families and only the weights you need
• Host fonts on your own domain where practical, and preload the main one
• Choose a fallback font of similar size, or adjust it with CSS font descriptors such as size-adjust, so the swap is barely visible
• Consider font-display: optional for body text: the web font is used only if it arrives almost immediately, so there's no late swap, though some first-time visitors will see the fallback

Banners, cookie notices and offer bars

Cookie notices, festival offer strips, "free delivery above" bars and app banners are frequent causes on business sites. When one is inserted at the top after the page has rendered, everything shifts down.

• Show notices as an overlay fixed to the top or bottom of the screen. Something that appears over the page without moving other content doesn't count as a layout shift.
• If a bar must sit in the page flow, include it in the page's HTML from the start instead of adding it with JavaScript later.
• Watch cached pages: some notice plugins decide with JavaScript whether to show a bar after the cached page loads, causing a late jump. Reserve its space or switch to an overlay.

Sticky and shrinking headers

These shifts only happen after scrolling, so lab tests often miss them.

• Switching to fixed: a header that becomes fixed on scroll leaves the page flow, and the content below jumps up by its height. CSS position: sticky keeps its space, or a placeholder of the same height can fill the gap.
• Shrinking: a header whose height changes on scroll moves content with it. Animate with transforms, which don't affect layout, or let the header sit over a fixed gap at the top of the page.
• Delayed scripts: if your optimisation plugin delays JavaScript until the visitor interacts, the header, menu or slider may look unfinished, then jump when its script runs. Exclude those scripts from the delay.

Confirm the fix

• Clear your caching plugin and any CDN cache, then re-test a few page types on mobile, scrolling each from top to bottom
• Field data covers a rolling 28 days, so Search Console takes a few weeks to catch up; use "Validate fix" once you're done
• Re-check after adding a plugin, ad, widget or banner, as each can bring shifts back

Most CLS fixes are small; finding the cause is the slow part. If you'd like it handled, my WordPress speed optimisation service covers all three Core Web Vitals. Planning a new site? With WordPress website development, space for images, embeds and headers is reserved from the start.