Everyone has experienced it. You start reading an article, an image loads above the text and everything moves down. You go to tap a button, a banner appears and you tap something else. It’s annoying at best and costly at worst, when an accidental tap lands on an ad or the wrong product. Cumulative layout shift is the metric that captures exactly this kind of frustration.
Google measures this as Cumulative Layout Shift, or CLS. It’s a score rather than a time: it combines how much of the screen moved and how far it moved. A score under 0.1 is good. Above 0.25 is poor.
The good news is that CLS is usually the easiest Core Web Vital to fix, because the causes are predictable. Almost every layout shift comes from content that appears or changes size without space reserved for it.
How to find what’s shifting
PageSpeed Insights
Run your page through PageSpeed Insights and look for the “Avoid large layout shifts” diagnostic. It lists the elements that shifted most during the test. That’s a good starting point, though it only captures shifts during page load in the lab.
Chrome DevTools
For a closer look, open DevTools, go to the Rendering tab (under More tools) and enable “Layout Shift Regions”. As the page loads and you scroll, shifted areas flash blue. Record a performance trace and the Layout Shifts track shows each shift with the elements involved.
Field data
Real users scroll, click and interact, which can trigger shifts that a lab test misses. Field data in Search Console and PageSpeed Insights shows the real-world CLS. If field CLS is much worse than lab CLS, the problem probably happens after load, during scrolling or interactions.
The common causes and their fixes
Images without dimensions
When an image has no width and height attributes, the browser doesn’t know how much space to reserve. It renders the text, then the image loads and pushes everything down.
WordPress adds width and height attributes to images inserted through the editor. Problems appear when:
- Themes output images with custom code that omits dimensions
- Page builders render images as backgrounds or with their own markup
- Images are added in custom HTML blocks
- CSS overrides height with height: auto without the browser knowing the aspect ratio
The fix is to always include width and height attributes. Modern browsers use them to calculate the aspect ratio, even when CSS makes the image responsive. For containers holding background images, use the CSS aspect-ratio property:
Web fonts swapping
When a custom font loads, text first renders in a fallback font, then switches. If the two fonts have different sizes, lines reflow and the page shifts.
Fixes:
- Preload the main font files so they arrive sooner.
- Self-host fonts rather than loading them from a third party, to avoid extra connections.
- Use font-display: optional for body text if you can accept the fallback on slow connections.
- Adjust the fallback font to match your web font’s metrics using the size-adjust, ascent-override and descent-override descriptors. Tools exist to calculate these values automatically.
Matching fallback metrics is one of the most effective font fixes and is underused.
Cookie consent banners
A banner that slides in at the top of the page pushes everything down. That’s a big shift on every first visit.
Position banners as overlays, fixed to the bottom or as a modal, so they don’t move page content. Most consent plugins have a position setting. Avoid “push down” or “top bar” styles.
Ads and embeds
Ad slots that load late and expand from zero height are a classic cause. So are YouTube videos, tweets, Instagram posts and maps that load in an iframe and resize.
Reserve space with a container of a fixed minimum height:
For ads, reserve space for the most common ad size in each slot. If the slot sometimes stays empty, a reserved empty space is better than a shift. For embeds, WordPress wraps many oEmbeds with responsive classes, but check that your theme supports them.
Content injected above existing content
Anything added to the page above what’s already visible causes a shift. Common examples:
- Notification bars and promotional banners loaded by JavaScript
- “You might also like” boxes that appear above article text
- Related products or recently viewed widgets loaded with AJAX
- WooCommerce notices added after load
If something must appear at the top, render it in the initial HTML rather than injecting it later. If it must load dynamically, reserve space for it or place it below the current viewport.
Lazy-loaded content without placeholders
Infinite scroll, lazy-loaded comment sections and “load more” features can cause shifts if the loading state is a different size from the loaded content. Use placeholders with the right dimensions, or skeleton screens that match the final layout.
Sliders and carousels
Sliders often render all slides stacked, then JavaScript arranges them into a carousel, causing a big shift. Others start at zero height until initialised.
Set a fixed height or aspect ratio on the slider container and hide non-active slides with CSS from the start, so the initial render matches the initialised state.
Animations that change layout
Animating properties like height, width, top or margin causes layout shifts. Animating transform and opacity doesn’t, because they don’t affect the position of other elements.
Expanding accordions and menus in response to a user click don’t count against CLS, because shifts within half a second of user input are excluded. But automatic animations, like entrance effects on scroll, do count.
Page builders and CLS
Page builders can be particularly prone to layout shift because of how they load. Some common builder-specific issues:
- Sections with entrance animations that start offset and move into place
- Sticky headers that change height when they become sticky
- Responsive settings applied by JavaScript after load rather than in CSS
- Icon fonts loading late, causing buttons and lists to resize
Most builders have settings to disable entrance animations and load icons as inline SVG. Turning off animations above the fold, at least on mobile, usually helps CLS noticeably.
Sticky headers deserve a mention
A header that becomes sticky as you scroll often shrinks or changes position. If it switches from position: relative to position: fixed, it leaves the document flow and everything below jumps up.
Fix it by keeping the header fixed from the start with a placeholder or padding of equal height, or by using position: sticky, which doesn’t remove it from the flow.
Check after every change
CLS regressions creep in easily. A new plugin adds a banner. A new ad network loads differently. A theme update changes image markup. Run PageSpeed Insights on your main templates after any significant change, and keep an eye on Search Console’s Core Web Vitals report.
Fixing CLS is rarely technically hard. It mostly requires noticing what moves and giving it a place to live before it arrives.
Testing on real devices and slow connections
Layout shifts often only appear on slower connections, where resources arrive further apart. On a fast office connection, the font, the images and the banner may all load before the first paint, so nothing visibly moves. On a mobile connection, they arrive one by one and the page jumps several times.
Use DevTools network throttling, set to a slow 4G profile, and reload the page with the cache disabled while Layout Shift Regions is turned on. Watch the whole load, then scroll slowly to the bottom of the page. Do the same on a real phone if you can. Anything that flashes blue is a candidate for reserved space.
Keeping CLS fixed
Once you’ve fixed the obvious causes, add a few checks to your routine so they stay fixed. When adding a new plugin that outputs anything visible, test the page for shifts before and after. When the marketing team adds a new banner or popup, check how it appears. When switching ad networks or adding a new embed type, reserve space before it goes live.
Theme developers can help by building space reservation into components: image blocks that always output dimensions, embed wrappers with aspect ratios and banner areas with fixed heights. Prevention in the design system is much cheaper than finding shifts one page at a time later.
Frequently asked questions
Does CLS affect SEO?
It’s part of Core Web Vitals, which are a ranking signal, though a modest one. More importantly, layout shifts frustrate users and cause accidental clicks.
Why is my CLS different on each test?
Shifts depend on timing: which resource loads first, network speed, ads served and so on. Run several tests and focus on field data for a reliable picture.
Do shifts after I click something count?
Shifts within 500 milliseconds of a user interaction are excluded, because they’re expected. Shifts that happen without interaction, or long after it, count.
Can lazy loading images cause CLS?
Only if the images lack dimensions. With width and height set, the browser reserves space and the image fills it when it loads, with no shift.
