Cumulative Layout Shift (CLS) is the Core Web Vital most visitors would describe simply as “the page jumping around.” An image loads late and pushes the text down, an ad slot appears where there was nothing before, or a cookie banner shoves the header out of the way just as someone reaches to tap it. Alongside Interaction to Next Paint in WordPress: How to Diagnose and Improve INP, CLS is one of three metrics tracked in the Core Web Vitals category. This guide covers how CLS is actually calculated, the most common WordPress-specific causes, and how to fix them without breaking the design.
What CLS measures
CLS quantifies unexpected movement of visible page elements, movement the visitor did not trigger themselves. Each individual layout shift is scored as its impact fraction (how much of the viewport was affected by the shift) multiplied by its distance fraction (how far the affected elements moved), and these individual shift scores are then grouped for the final metric. Layout shifts caused directly by a user’s own action, expanding an accordion by clicking it, for example, are explicitly excluded from the measurement; it is the unexpected movement that counts.
Current CLS thresholds
As of 2026, Google’s thresholds for CLS are: good at 0.1 or less, needs improvement between 0.1 and 0.25, and poor above 0.25, assessed at the 75th percentile of real page loads, with mobile and desktop measured separately.
Field data versus lab testing
Lab tools such as Lighthouse only observe layout shifts that occur during a single simulated page load; they cannot capture shifts that occur later, triggered by a visitor scrolling, a delayed ad request, or content injected well after the initial load. Field data (CrUX, visible in Search Console or PageSpeed Insights) reflects the real, complete session, including shifts that happen at any point while the page remains open, which is why a page can test as “good” in a lab tool while still showing a worse CLS score in real-user field data.
Layout shift score and session windows, in plain language
Google groups nearby shifts into session windows: shifts less than one second apart can join the same window, which lasts no more than five seconds. The highest-scoring window becomes the page’s CLS value instead of adding every unrelated shift across the visit.
Images and videos without reserved dimensions
The single most common cause of CLS across the web is an image or video that has no reserved space in the layout before it finishes loading; when it arrives, the browser has to insert it into a space that wasn’t accounted for, pushing surrounding content out of the way. Setting explicit width and height attributes (or a CSS aspect-ratio) allows the browser to reserve the correct amount of space immediately, before the actual file has downloaded, which prevents this kind of shift entirely.
Responsive image sizing
Responsive images, using srcset to serve different files at different viewport widths, still need a consistent aspect ratio reserved regardless of which specific file ends up loading; if the various available image sizes don’t share the same aspect ratio, the reserved space can end up wrong for whichever size is actually served to a given visitor. As covered in How to Optimize Images and the LCP Element in WordPress, WordPress generates srcset and sizes attributes automatically since WordPress 4.4, but the underlying width/height attributes still need to be present and accurate for layout stability to actually hold.
Ads, embeds, cookie notices, and banners
Advertising slots are a particularly common CLS cause because the actual ad creative often loads asynchronously, after the surrounding page content, and can vary in size depending on which ad happens to be served. Reserving a fixed-size container for an ad slot in advance, even if the specific ad hasn’t loaded yet, prevents the surrounding content from shifting once it does. The same principle applies to embedded third-party content (social media posts, video embeds) and to cookie-consent banners or notification bars: any element capable of appearing after the initial page render needs space reserved for it in advance, or it needs to be positioned in a way that doesn’t displace existing content (for example, as an overlay rather than pushing content down).
Web fonts and font swapping
When a custom web font replaces a fallback system font partway through the page load (the “swap” behavior discussed as part of font-display: swap), the new font’s different letter widths and line heights can cause visible text to reflow, shifting everything below it. As covered in WordPress Fonts, CSS, Scripts, and Plugin Weight Explained, using font-display: optional, preloading the critical font file, or choosing a fallback font with closely matched metrics, all reduce the visual impact of this kind of shift.
Dynamically injected content
Any content inserted into the page after the initial render, a “related posts” block that loads via JavaScript, a live comment count, or a personalized recommendation widget, can cause a shift if it’s inserted above content the visitor is already looking at. Where the design allows, inserting this kind of content below the fold, or reserving a placeholder of the correct approximate size in advance, reduces the disruptive effect even when the exact content can’t be known ahead of time.
Sticky headers and navigation
A sticky or fixed header that changes height after the page loads, commonly because it collapses to a smaller size once a visitor scrolls, or because it waits for a logo image or menu to finish rendering before settling into its final size, can cause the entire page’s content to shift underneath it. Setting a fixed, reserved height for sticky elements before their contents load helps avoid this.
Animations and transitions
Animating layout-affecting CSS properties (width, height, margin, or position, for example) causes the browser to recalculate layout on every frame of the animation, which can register as a layout shift if it happens unexpectedly. Animating transform and opacity instead, which do not require the browser to recalculate layout, achieves many common visual effects (sliding, scaling, fading) without the same layout-shift risk.
WordPress themes and page builders
Page builder plugins and heavily templated themes often introduce their own CSS and JavaScript that can affect layout stability independently of anything in the actual post content, for example, a builder that applies its final styling only after its own JavaScript runs, briefly showing unstyled or differently sized elements first. Testing representative page-builder templates specifically, not just plain content pages, is worth doing separately, since layout stability issues on these templates are often introduced by the builder itself rather than by any content a site owner has direct control over.
Lazy-loaded content
Lazy-loaded images are generally safe for CLS as long as their space is still reserved in advance via width/height attributes, since the browser knows how much room to leave even though the actual file hasn’t downloaded yet. The risk arises specifically when a lazy-loaded element has no reserved dimensions at all, in which case the browser has no way to leave appropriate space and a shift occurs the moment the content actually arrives, regardless of whether that arrival was “lazy” or immediate.
Identifying shifts in Chrome DevTools
Chrome DevTools’ Performance panel includes a dedicated Layout Shift track, which highlights exactly when a shift occurred during a recorded session, which specific element(s) moved, and the shift’s contribution to the overall score. This is the most direct way to confirm a suspected cause rather than guessing, particularly for shifts that happen after the initial page load, such as those triggered by scrolling or delayed content.
Using PageSpeed Insights and real-user data
PageSpeed Insights can show a Lighthouse load test and, when sufficient CrUX data exists, a field CLS result. Good lab CLS with poor field CLS usually points to shifts triggered later, which require manual testing or DevTools.
Reserving space with aspect ratio and dimensions
Beyond standard images, the same principle, reserving space in advance using explicit dimensions or the CSS aspect-ratio property, applies to video embeds, iframes, and any other replaced element whose final size is known ahead of time even if its content loads later. This is generally the single most effective and lowest-risk category of CLS fix, since it addresses the root cause (unreserved space) rather than working around a symptom.
Safe font-loading strategies
Choosing font-display: optional for body text avoids the visible swap-related shift entirely, at the cost of occasionally keeping the fallback font for a visitor’s entire page view if the custom font arrives late. Preloading the most-used font file increases the odds the custom font wins the race and displays correctly even under optional. Matching a fallback font’s general proportions to the custom font, where design tools support this, further reduces the visual jump on the occasions a swap does occur.
Mobile-specific layout shifts
Smaller mobile viewports amplify the visible impact of a given shift, since the same pixel movement represents a larger proportion of the visible screen. Mobile-specific elements, sticky mobile menus, mobile-only banners, and touch-optimized ad formats, are worth testing separately from desktop, since a shift that’s barely noticeable on a wide desktop viewport can be much more disruptive on a phone screen.
Verification after fixes
After applying a fix, re-test using Chrome DevTools’ Layout Shift track on the same page, and also check whether the fix required scrolling or interacting with the page in the way a real visitor would, since some shifts only appear under those conditions. As with other Core Web Vitals, allow time for field data in Search Console to reflect the change before drawing final conclusions, since CrUX aggregates over a rolling window rather than updating instantly.
Common CLS mistakes
- Setting image dimensions in CSS only, without the underlying HTML
width/heightattributes the browser needs to reserve space early - Assuming a good lab CLS score means the page is fine, when field data reflects a longer real-user session lab tools cannot see
- Not reserving space for ad slots, embeds, or cookie banners that load after the initial render
- Animating layout-affecting CSS properties instead of transform/opacity for the same visual effect
- Only testing desktop, missing mobile-specific shifts caused by smaller viewports
- Using
font-display: swapwithout considering the layout impact of the resulting font swap
Practical CLS checklist
- Confirm all images and videos have explicit width/height attributes or a CSS aspect-ratio set
- Reserve fixed-size containers for ad slots, embeds, and cookie/notification banners
- Choose a deliberate font-loading strategy (optional or swap with preload) rather than the default
- Avoid animating layout-affecting properties; use transform and opacity instead
- Test sticky headers and navigation for height changes after their content finishes loading
- Check page-builder templates separately from plain content pages
- Use Chrome DevTools’ Layout Shift track to confirm the actual cause before applying a fix
- Test on mobile viewports specifically, not just desktop
Key Takeaways
- CLS measures unexpected layout movement, scored by impact fraction times distance fraction and grouped into session windows.
- Current thresholds are good at 0.1 or less and poor above 0.25, assessed at the 75th percentile across mobile and desktop separately.
- The most common cause is unreserved space for images, videos, ads, and embeds; explicit dimensions or aspect-ratio fix this directly.
- Lab tools only see shifts during the initial simulated load; field data reflects the full real-user session and can reveal later-occurring shifts lab tools miss.
- Mobile viewports amplify the visible impact of a given shift, making mobile-specific testing worthwhile.
FAQs
Why does my page have a good CLS score in Lighthouse but a worse score in Search Console?
Lighthouse only measures shifts during its simulated initial page load. Search Console’s field data reflects the complete real-user session, including shifts triggered later by scrolling, delayed ads, or dynamically injected content that a lab test cannot see.
Does lazy loading cause layout shift?
Not by itself. Lazy-loaded images are safe for CLS as long as their space is reserved in advance with width/height attributes. The shift occurs specifically when no space is reserved, regardless of whether the image loads immediately or lazily.
Should I avoid animations entirely to protect my CLS score?
No. Animating properties like transform and opacity does not trigger layout recalculation and is generally safe for CLS. The risk is specifically with animating layout-affecting properties such as width, height, or margin.
How much does a cookie consent banner typically affect CLS?
It depends entirely on implementation. A banner that overlays content without pushing it down generally has minimal CLS impact; one that inserts itself above existing content and pushes everything else down can cause a significant shift, particularly if it appears with any delay after the initial render.
Is a CLS of exactly 0 realistic for a content-heavy WordPress site?
It’s achievable but requires consistent discipline across every image, embed, ad slot, and dynamic element on every template. Many well-optimized sites comfortably stay under the 0.1 “good” threshold without necessarily reaching exactly zero, which is a reasonable practical goal.
