WordPress sites pass or fail Core Web Vitals on four levers: how fast the server answers (hosting and page caching), how much the theme or page builder sends, what plugins add to every page, and how images are loaded. WordPress core itself helps: it lazy-loads images below the fold, marks the likely LCP image with fetchpriority="high" and adds image dimensions. Most failing WordPress Core Web Vitals come from what is installed on top of core, and each metric has its usual WordPress culprits.
This guide is for WordPress site owners and the people who build and maintain their sites. It goes metric by metric: what fails LCP, INP and CLS on WordPress, how to find it, and the fix. For the metrics themselves, read Core Web Vitals explained for site owners; for a general speed-up checklist, see how to speed up a WordPress site.
Quick answer
- LCP fails on WordPress because of a slow uncached server, a hero image or slider that is lazy-loaded or oversized, and builder CSS and scripts that block rendering.
- INP fails because of JavaScript: page builder widgets, sliders, pop-ups, chat, tag managers and WooCommerce add-ons all running on the main thread.
- CLS fails because of cookie banners and notices pushing content, ads without reserved space, web fonts swapping and builder images without dimensions.
- One page cache, a current PHP version and a host that answers cached pages in under 300 ms are the base for a good LCP.
- Let core do its job: do not let a theme, builder or plugin lazy-load the first image.
- Measure in the field with real-visitor data and wait 28 days after a fix.
How to see where your WordPress site stands
The Core Web Vitals test shows LCP, INP and CLS from the Chrome UX Report for the page and the whole site, rated against Google's thresholds, with a Lighthouse lab run that names the LCP element and the scripts responsible. Test a post or product page and a category or archive page as well as the home page: on WordPress they often use different templates and different builder layouts.
Then see what the page loads, plugin by plugin:
The detector names the theme and page builder, and matches every request on the page to its plugin with its kilobytes and load time. That turns "too much JavaScript" into "the slider plugin loads 280 KB on pages without a slider".
What WordPress core does for Core Web Vitals
Recent WordPress versions include performance features that help all three metrics without a plugin:
- Lazy loading. Since WordPress 5.5, images get
loading="lazy", and core tries to leave the first images in the content eager so the LCP image is not delayed. - Fetch priority. Since 6.3, core adds
fetchpriority="high"to the image it expects to be the LCP element. - Dimensions. Core adds
widthandheightto images in post content, which prevents layout shifts. - Modern formats. WebP uploads work since 5.8 and AVIF since 6.5.
- Speculative loading. Since 6.8, WordPress prefetches a page when a visitor starts clicking a link to it, which makes the next page's LCP faster.
- Block themes and block CSS. Block themes load the CSS of core blocks only for the blocks on the page.
The WordPress Performance Team's Performance Lab plugin adds feature plugins that are not in core yet, such as Image Prioritizer and Embed Optimizer. They are optional; a site with a working page cache and sensible images can pass without them.
The catch is that themes, page builders and optimisation plugins can override core. A slider that lazy-loads its first slide, or a plugin that adds loading="lazy" to every image, undoes the LCP work. The lab result shows which element is the LCP and whether it is lazy-loaded.
LCP on WordPress
LCP is the metric WordPress sites fail most. Work through the four parts of it:
1. The server's first byte. An uncached WordPress page runs PHP and dozens of database queries for every visitor; on shared hosting that can take over a second, and LCP can never be faster than it. The fix is exactly one page cache (the host's own, LiteSpeed Cache on LiteSpeed servers, or one caching plugin), a current PHP version and, if the server is still slow, the steps in slow server response time on WordPress. Two caching plugins at once are a common cause of a cache that does not work.
2. The hero image. On most WordPress home and landing pages the LCP element is a hero image, a slider's first slide or a builder section background. Common problems:
- Uploaded at camera size, several megabytes. Resize to about 2,000–2,500 px for full width and serve WebP or AVIF.
- Lazy-loaded by the slider, the builder or an optimisation plugin. Exclude the first image from lazy loading; most caching plugins have an "exclude from lazy load" field or a setting for the first images.
- Set as a CSS background in the builder. The browser finds it only after the CSS has loaded. Use an image element where the builder allows it, or preload the image.
3. Builder and theme CSS and JavaScript. Page builders load their frameworks, icon fonts and animation libraries, often in the <head>. Turn on the builder's performance options (optimised asset loading, per-page CSS), remove entrance animations from the first screen, and use your caching plugin's defer and unused-CSS options one at a time. The Elementor and Divi guides have the settings.
4. Web fonts. A headline that waits for a Google Font delays LCP when the headline is the largest text. Host fonts locally (most themes and builders have a setting), limit the weights, and use font-display: swap.
The caching plugin guides cover the switches tab by tab: WP Rocket settings for Core Web Vitals and LiteSpeed Cache settings for Core Web Vitals.
INP on WordPress
INP fails when the page is busy running JavaScript at the moment a visitor taps. On WordPress, that JavaScript comes from a predictable list:
- Page builder widgets (tabs, accordions, carousels, animations) and the frameworks behind them.
- Plugins that load everywhere: sliders, pop-ups, social sharing, related posts, forms loaded on pages without a form.
- Third-party scripts: tag managers with many tags, chat widgets, heatmaps, A/B testing, ad scripts.
- WooCommerce extras: cart fragments, product filters, variation swatches and upsell widgets, especially on category pages.
The fixes, in order: remove plugins and tags that do not earn their place; stop the rest from loading on pages that do not use them (plugin settings, or an asset manager); delay third-party scripts until the first interaction with your caching plugin, excluding anything the first screen needs, such as the menu or the cookie banner; and move tracking into one tag manager container you keep lean.
If the lab's Total Blocking Time is low but field INP is poor, the slow interaction happens later: opening the mobile menu, filtering products, adding to cart. Record it in Chrome's developer tools → Performance panel and look for the plugin script in the long task. Fix Interaction to Next Paint explains how. On shops, WooCommerce cart fragments is a frequent culprit.
CLS on WordPress
WordPress layout shifts usually come from something added by a plugin or the theme above the content:
- Cookie consent banners and notice bars inserted at the top of the page, pushing everything down. Configure them as an overlay at the bottom of the screen.
- Ads and embeds (AdSense, YouTube, social posts) without a reserved height. Give their containers a
min-height. - Images in builder sections without dimensions. Core adds
widthandheightto content images, but builder widgets and theme templates do not always. The image findings list images missing them. - Web fonts swapping from the fallback to the theme font and reflowing text. Match the fallback size or preload the main font; see web fonts without layout shift.
- Lazy-loaded content above the fold that expands when it loads, such as a slider whose height is only known after its script runs. Give the slider a fixed aspect ratio.
Fix Cumulative Layout Shift has the CSS for each pattern.
Hosting and Core Web Vitals
Hosting mostly affects LCP, through the first byte, and it sets a floor no front-end work can go below. The signs that the host is the limit: cached pages still answer slower than 600 ms from nearby, or the first byte swings widely during busy hours. Before moving, compare hosts with your own measurements; choosing a WordPress host by measured TTFB shows how. A CDN in front helps visitors far from the server, once the page cache works.
Confirm the result
Lab numbers move as soon as you clear the cache and re-test. The real-visitor numbers that decide the assessment cover 28 days, so they catch up over about four weeks.
The Core Web Vitals report tool plots up to 40 weeks of Chrome UX Report data for your site or a popular page against the thresholds. A plugin update, a new builder version or a new tag often shows up as the week a line crossed into "poor", which tells you what to look at. For the general plan when more than one metric fails, see how to improve Core Web Vitals.
Common mistakes
- Installing a second optimisation plugin to fix what the first one broke.
- Lazy-loading every image, including the first slide or hero, often through a plugin setting that overrides core.
- Testing while logged in, which bypasses the page cache and adds the admin bar.
- Delaying all JavaScript without exclusions, so the menu or cookie banner stops working until the visitor taps.
- Fixing the home page only while product, post and archive templates fail.
- Blaming WordPress for what a builder, slider or tag manager sends.
Questions people ask
Can a WordPress site pass Core Web Vitals?
Yes. WordPress core includes lazy loading, fetch priority for the likely LCP image, image dimensions and speculative loading, and many WordPress sites pass all three metrics. Failures usually come from what is added on top: no page cache or slow hosting, a heavy page builder, plugins loading scripts on every page, lazy-loaded hero images and cookie banners that push content. Fix those and WordPress is not the limit.
Do page builders make Core Web Vitals fail?
They make it harder, mostly for LCP and INP. Builders such as Elementor and Divi load their own CSS, JavaScript and icon fonts and wrap content in extra HTML, which delays rendering and adds main-thread work. Turning on their performance settings, removing animations from the first screen and limiting widgets usually brings pages into the good range. The block editor starts with less code.
Which WordPress plugins hurt INP the most?
The ones that run JavaScript on every page: sliders and carousels, pop-up and opt-in tools, social sharing buttons, chat widgets, heatmaps, A/B testing, ad scripts and tag managers with many tags. On shops, product filters, swatches and cart fragments add more. A plugin detector that measures each plugin's scripts shows which ones to remove, restrict to certain pages or delay until the visitor interacts.
Is a caching plugin enough to pass Core Web Vitals on WordPress?
Usually not on its own. A page cache fixes the server part of LCP, and settings like deferring JavaScript and removing unused CSS help more. But a caching plugin cannot shrink an oversized hero image uploaded at camera size, remove a heavy plugin, or stop a cookie banner from pushing the page down. Use one caching plugin well, then fix images, plugins and layout shifts.
Why do WordPress sites often fail CLS on mobile?
Because the things that shift content are more visible on a small screen: cookie banners and notice bars inserted at the top, ads and embeds without reserved height, sliders whose height is set by JavaScript, and web fonts that reflow narrow columns of text. Overlay banners at the bottom, give ad and slider containers fixed dimensions, and match the fallback font to the web font.