Fixing Layout Shift on a WordPress Site
A WordPress page is assembled from a theme, a handful of plugins and often a page builder, and any of them can make the page jump.
The usual suspects are theme templates that print images without dimensions, slider and builder sections that size themselves with JavaScript, performance plugins whose CSS and script tricks change how the first paint looks, and fonts loaded by the theme or builder. This guide shows how to work out which part of your WordPress stack is responsible, and the settings or template changes that fix each one without breaking the site.
- Where WordPress sites usually shift
- Finding which plugin or template is responsible
- Images: what WordPress does and does not handle
- Sliders and page builder sections
- When optimisation plugins cause the shift
- Fonts from the theme or builder
- The fix, step by step
- Keeping WordPress stable after updates
- Questions and answers
Where WordPress sites usually shift
| Part of the stack | How it shifts |
|---|---|
| Theme templates | Featured images, logos and card images printed with a bare <img src>,
so the browser does not know their size |
| Content from old posts | Images pasted as HTML or from other sites, which WordPress cannot add dimensions to |
| Slider plugins | Slider height calculated by JavaScript after load, or all slides visible until the script runs |
| Page builders | Sections that depend on scripts for layout, sticky headers built with JavaScript, carousels and tabs |
| Performance plugins | Critical or reduced CSS missing some styles; delayed JavaScript leaving menus and widgets in their unstyled state |
| Fonts | Google Fonts loaded by the theme or builder, with a late swap |
| Ads, consent and pop-up plugins | Content inserted into the page flow after load |
| WooCommerce | Mini-basket counts and notices updated by script after the page loads |
Ad slots and consent notices have their own guides: CLS from ads and CLS from dynamic content. This guide covers the parts that are specific to how WordPress builds pages.
Finding which plugin or template is responsible
Two WordPress habits hide layout shift from site owners. First, most people check their site while logged in, which shows the admin toolbar and often bypasses the page cache and some optimisation plugins. Visitors get a different page. Second, a caching plugin may serve an old copy, so a change you made does not appear straight away.
- Test logged out. Use a private browser window, or test a staging copy, so you see exactly what visitors see.
- Run the CLS Debugger on the home page, a blog post, a page built with your builder and, for shops, a product page. Note each shifted element and its score.
- Identify the owner of each element. Inspect the moved element, or the element above it that appeared, in Chrome DevTools. Class names usually reveal the source: builder classes, a slider plugin's prefix, a theme's prefix or a WooCommerce class.
- Switch plugins off safely. On staging, deactivate suspects one at a time. On a live site, the Health Check and Troubleshooting plugin has a troubleshooting mode that disables plugins and switches to a default theme for your session only, leaving visitors unaffected. Retest after each change.
- Compare with optimisation off. Turn off your performance plugin's CSS and JavaScript features and retest. If CLS improves, the problem is in how those features are configured, covered below.
Images: what WordPress does and does not handle
Since version 5.5, WordPress adds width and height attributes to images
in post content when they are missing, as long as it can recognise the image as a Media Library upload
(it looks for the wp-image- class the editor adds). Images inserted with the block editor
or the classic editor's Add Media button are covered. Images pasted as raw HTML, hot-linked from another
site or added by a shortcode usually are not.
Theme templates are a separate matter. A template that prints the featured image like this gives the browser no size:
<img src="<?php echo esc_url( get_the_post_thumbnail_url( null, 'large' ) ); ?>"
alt="<?php the_title_attribute(); ?>">WordPress functions that build the whole tag include width, height, srcset and sizes for you:
<?php
the_post_thumbnail( 'large' );
// or, for any attachment ID:
echo wp_get_attachment_image( $image_id, 'large', false, array( 'class' => 'card__img' ) );
?>If the theme is not yours to edit, create a child theme and override the template there, so a theme update does not undo the change. Several performance plugins also have an option to add missing image dimensions; it can fill gaps in old content, but fixing the template is more reliable.
Background images do not shift
A CSS background image does not affect layout, so a builder section with a background photo will not move when the photo arrives. The section's height comes from its content and settings. If such a section does shift, look at its content or its height setting, not the background.
Lazy-loading plugins
WordPress lazy-loads images natively. Some older lazy-loading plugins replace the real image with a tiny placeholder and swap the address in with JavaScript; if the placeholder has no dimensions, the image box starts collapsed. With native lazy loading available, those plugins are usually unnecessary.
Sliders and page builder sections
Slider plugins are one of the most common sources of large shifts on WordPress home pages, because they sit at the top and often wait for their script to decide the slider's height. Most slider plugins offer a layout choice such as fixed, auto or full width. A fixed height, or a height derived from a set aspect ratio, lets the space be reserved in CSS. Settings that calculate height from the tallest slide once all images are loaded tend to shift.
Page builders render sections as HTML, so most of the layout is present at first paint. Problems come from widgets that finish their layout in JavaScript:
- Carousels and testimonial sliders that show every item stacked until their script runs.
- Tabs and accordions that show all panels until the script hides the inactive ones.
- Sticky headers built with the builder, which can remove the header from the page flow when they become sticky, pulling the content up.
- Counters and animated headings whose width changes as the text changes.
- Entrance animations, which are usually harmless when they animate opacity and transform, but custom ones that animate margins or height do move content.
Where a builder widget offers a fixed height or aspect ratio setting, use it. Otherwise give the widget
a custom CSS class and set a min-height for it in the builder's custom CSS panel or the
child theme stylesheet. The general technique for scripted widgets is covered in the components
guide.
When optimisation plugins cause the shift
Caching and optimisation plugins improve load times, but three of their features change what the first paint looks like, and misconfigured they add layout shift.
| Feature | How it can cause shift | What to do |
|---|---|---|
| Remove unused CSS or reduced CSS | Styles needed for content added later by script, or for some templates, are stripped from the first load; the page is drawn wrongly then corrected when full CSS loads | Add the missing selectors to the plugin's safelist, or exclude the affected template |
| Critical CSS with the rest loaded asynchronously | If the generated critical CSS is incomplete, the first screen is partly unstyled until the full stylesheet arrives | Regenerate critical CSS after theme or builder changes, and check each template |
| Delay JavaScript until interaction | Menus, sliders and tabs sit in their unstyled pre-script state until the visitor scrolls or moves the mouse; the shift that follows is not exempt | Exclude scripts that affect layout above the fold from delay, or give those components their final size in CSS |
It is common to see CLS rise straight after switching on an optimisation feature, while LCP improves. Keep the feature and fix its configuration rather than turning it off entirely, unless you cannot find the cause.
Fonts from the theme or builder
Many themes and builders load Google Fonts from Google's servers with display=swap, which
draws text in a system font first and redraws it later. Options, depending on your set-up:
- Block themes define fonts in
theme.json. Font faces there can include afontDisplayvalue, and the Font Library in recent versions of WordPress installs font files locally rather than loading them from Google. - Classic themes and builders often have a setting to host Google Fonts locally or to choose the font display value. If not, a local fonts plugin can download the files and rewrite the requests.
- Fewer weights. Builders make it easy to use a different weight in every widget. Each is a separate file and a separate reflow.
Once fonts are local, preload the main body font and consider tuning the fallback font, as described in the web fonts guide.
WooCommerce specifics
WooCommerce updates the mini-basket count and total with a script after the page loads on many themes. If the header sizes itself to that text, a change from an empty basket to "3 items, £84.50" can widen it and wrap the menu. Give the basket link a fixed width. Notices such as "added to basket" are covered in the banner guide.
The fix, step by step
Step 1
Test logged out on a staging copy
Create a staging copy through your host or a staging plugin, so you can change settings without affecting visitors. Run the CLS Debugger on a logged-out view of the home page, a post, a builder page and a shop page if you have one, and record a throttled mobile load in Chrome DevTools while scrolling. Note every shifted element and its score, and keep the results to compare with later.
Step 2
Find the plugin or theme part responsible
Inspect each shifted element, and the element above it that appeared or grew, and use its class names to work out whether it comes from the theme, the builder, a slider, WooCommerce or another plugin. Confirm by deactivating the suspect on staging, or with the Health Check and Troubleshooting plugin's session-only mode on a live site, and retesting. Also retest with your optimisation plugin's CSS and JavaScript features switched off.
Step 3
Output images with WordPress functions
In
a child theme, replace template code that prints bare image tags from get_the_post_thumbnail_url()
or custom fields with the_post_thumbnail() or wp_get_attachment_image(), which
include width, height and srcset. For old posts with pasted or hot-linked images, re-insert them from
the Media Library or add dimensions by hand. Remove any lazy-loading plugin that swaps in placeholders
without dimensions, since WordPress now lazy-loads images natively.
Step 4
Fix sliders and builder sections
Set
sliders to a fixed height or fixed aspect ratio rather than one calculated from slide content, or replace
a slider at the top of the page with a single static image. For builder widgets that shift, such as carousels,
tabs and counters, use fixed height options where they exist, or add a CSS class and a min-height
in custom CSS. Check that sticky headers keep their space when they detach.
Step 5
Check optimisation plugin settings
If CLS got better with optimisation features off, turn them on again one at a time. For removed or reduced CSS, add missing selectors to the safelist. For critical CSS, regenerate it and check each template. For delayed JavaScript, exclude the scripts for your menu, slider and other above-the-fold components. Clear the plugin cache, host cache and CDN after each change, then run the CLS Debugger again.
Step 6
Load fonts locally with a stable display value
Find where fonts come from: the theme customiser, theme.json, the builder's
settings or a plugin. Host them locally using the Font Library, the builder's local fonts option or a
local fonts plugin, and reduce the families and weights in use. Set a font display value of optional
for body text where the setting is offered, preload the main body font, and remove duplicate font requests
added by other plugins.
Step 7
Clear every cache and retest
Push the changes from staging to live, then clear the caching plugin, any host-level cache and your CDN. Run the CLS Debugger again on the same pages as in step one while logged out, and compare the scores and the list of shifted elements. Repeat the throttled mobile recordings. Then watch the Core Web Vitals report in Search Console over the following four weeks as real-visitor data catches up.
Keeping WordPress stable after updates
- Retest after plugin, theme and builder updates. Updates change markup and scripts, and a stable page can start shifting without any change on your part.
- Keep template changes in a child theme so theme updates do not overwrite them.
- Regenerate critical CSS whenever you change the theme, builder layouts or header.
- Be sparing with plugins that add front-end content. Each pop-up, bar, badge or widget is another thing that can arrive late.
For overall speed on WordPress, see Core Web Vitals on WordPress and page speed on WordPress.
1. Does WordPress add image dimensions automatically?
Partly. Since version 5.5, WordPress adds width and height to images in post content when they are missing, provided it can identify the image as a Media Library upload. It cannot do this for images pasted as HTML, loaded from other websites or added by some shortcodes. Theme templates are also outside this feature, so a theme that prints featured images with a bare image tag needs changing to use the_post_thumbnail or wp_get_attachment_image.
2. Why did my CLS get worse after installing a caching plugin?
Usually because of one of its CSS or JavaScript features rather than caching itself. Removing unused CSS or loading CSS asynchronously can leave the first screen partly unstyled until the full stylesheet arrives. Delaying JavaScript leaves sliders, menus and tabs in their pre-script state until the visitor interacts, and the jump that follows counts. Turn the features on one at a time, testing in between, to find which one needs adjusting.
3. Do page builders like Elementor or Divi cause layout shift?
Page builders are not a cause in themselves, since they output normal HTML and CSS for most sections. Shifts come from particular widgets that finish their layout with JavaScript, such as carousels, tabs, counters and sticky headers, and from fonts the builder loads. Fixing those widgets with fixed heights or custom CSS, and hosting fonts locally, usually brings a builder page within the good threshold. Check each widget type separately.
4. Why does my site look fine when I am logged in but shift for visitors?
When you are logged in, WordPress usually shows the admin toolbar and many caching and optimisation plugins serve you an uncached, unoptimised page. Visitors get the cached, optimised version, which may load CSS and scripts differently and so shift differently. Always test layout shift in a private window or while logged out, and clear caches after making changes, so you see exactly the page visitors see. Test on a phone-sized screen as well, since mobile layouts often shift differently.
5. Is a slider bad for CLS on WordPress?
Not necessarily, but many slider plugins are. A slider at the top of the home page affects the whole screen, so any change in its height after load produces a large shift. If the slider uses a fixed height or a fixed aspect ratio that can be reserved in CSS, and shows the first slide correctly before its script runs, it can be stable. Replacing it with a single well-chosen image is often simpler and faster.
6. Should I host Google Fonts locally on WordPress?
It usually helps. Local fonts avoid connections to Google servers and let you preload the main font file so it is more likely to arrive before the text is drawn, which reduces or removes the swap. Block themes can use the Font Library, many builders have a local fonts option, and there are plugins that download and rewrite font requests. Check the font licence and remove any remaining requests to Google afterwards.
The CLS Debugger records every layout shift as a page loads, names the elements involved, calculates the cumulative score and ranks each shift by impact, so you can trace it to the theme, builder or plugin responsible.
Open CLS Debugger Fixes →