WordPress Core Web Vitals: Which Plugins Actually Help

Most WordPress sites that fail Core Web Vitals do not need more plugins; they need the right two or three, configured properly, and nothing doing the same job twice. This guide to WordPress Core Web Vitals explains which plugin types genuinely move LCP, INP and CLS, what WordPress core already does for you, how to measure before and after, and the overlaps that make sites slower. If you want the general speed checklist (hosting, caching, database clean-up), read our guide to speeding up a WordPress site first; this post focuses on the three metrics Google reports.

Key takeaways

Most WordPress sites failing Core Web Vitals need the right two or three plugins configured properly, not more plugins.
Most sites need one page cache, one image optimiser and a way to defer or delay non-essential JavaScript.
WordPress has had native lazy loading since version 5.5, so extra lazy-loading plugins can lazy-load the hero image and hurt LCP.
Record a baseline and change one thing at a time, as field data takes up to 28 days to reflect a change.

The targets: what "passing" means

Google's Core Web Vitals thresholds, measured at the 75th percentile of real page loads, are:

Metric	Measures	Good
Largest Contentful Paint (LCP)	Loading: when the main content appears	2.5 seconds or less
Interaction to Next Paint (INP)	Responsiveness to taps, clicks and key presses	200 ms or less
Cumulative Layout Shift (CLS)	Visual stability	0.1 or less

A plugin can only improve the metric it actually affects. An image optimiser will not fix INP, and a script-delay plugin will not fix a slow server. Diagnose which metric is failing, and why, before installing anything.

Measure before you change anything

Without a baseline you cannot tell whether a plugin helped, did nothing or made things worse.

Pick three to five representative URLs: the home page, a typical post or service page, and (on WooCommerce) a product and category page. Templates matter more than individual pages.
Record field data. In PageSpeed Insights, the top section ("Discover what your real users are experiencing") shows Chrome UX Report data for the URL or origin. Search Console's Core Web Vitals report groups URLs by template and status.
Record lab data. Run each URL three times on mobile in PageSpeed Insights and note the median LCP, Total Blocking Time (a lab proxy for INP) and CLS, plus the LCP element shown in the diagnostics.
Test logged out. Caching and most optimisation plugins skip logged-in users, and WordPress disables speculative loading for them too. Use a private window.
Change one thing at a time, clear every cache layer, then re-test the same URLs.

Field data takes up to 28 days to reflect a change, because the Chrome UX Report uses a rolling window. Use lab data to confirm a fix works, and field data to confirm real users benefit.

What WordPress core already does

Recent WordPress releases have added several performance features that older optimisation plugins also provide. Knowing them helps you avoid duplicates.

Feature	Since	What it does
Native lazy loading	5.5	Adds `loading="lazy"` to images and iframes, skipping the first content images
`fetchpriority="high"`	6.3	Adds high priority to the image WordPress judges most likely to be the LCP element
`sizes="auto"`	6.7	Lets the browser pick the right image size for lazy-loaded images
Speculative loading	6.8	Prefetches the next page when a user starts clicking a link (logged-out visitors only)

Two practical consequences:

You may not need a separate lazy-loading plugin. If your theme, a page builder and a plugin all add lazy loading, you can end up with the hero image lazy-loaded, which hurts LCP.
Core's LCP detection is a best guess. WordPress picks the image based on its position and size on the page, without knowing what actually renders largest on each device. On themes where the hero is a background image or slider, you usually need to set it yourself.

The Performance Lab plugin from the WordPress Performance Team lets you test upcoming features as separate plugins, including Image Prioritizer, Modern Image Formats (WebP/AVIF uploads), Enhanced Responsive Images and Speculative Loading options. They are well maintained and designed not to conflict with core.

Plugin types that actually help, by metric

Plugin type	Main metric	Why it helps
Page caching	LCP	Serves pre-built HTML, cutting server response time (TTFB)
Persistent object cache (Redis/Memcached)	LCP	Speeds up uncached and dynamic pages, including WooCommerce carts
Image optimisation	LCP	Smaller files in WebP or AVIF, resized to display size
Script deferral or delay	INP, LCP	Stops non-essential JavaScript competing with rendering and input
Font handling	LCP, CLS	Hosts fonts locally, preloads key files, reduces swap shifts
Critical or unused CSS removal	LCP	Reduces render-blocking CSS (higher risk of breakage)

Caching: fix TTFB first

If your server is slow to send the first byte of HTML (a high TTFB), LCP will struggle whatever else you do. Use one page cache: either your host's built-in cache or a caching plugin, not both, unless the host explicitly recommends a specific plugin. Pair it with a persistent object cache if your host offers Redis or Memcached.

Image optimisation: shrink the LCP image

Choose a plugin that converts to WebP or AVIF, resizes oversized uploads and serves the right size through srcset. Pick one image optimiser and remove any others, or you will generate duplicate files and conflicting markup.

Script deferral: the biggest INP lever

Deferring JavaScript lets the page render first; "delaying" it until user interaction goes further for things like chat widgets, heatmaps and social embeds. This is often the single largest INP improvement on plugin-heavy sites, but it is also the most likely setting to break functionality. Exclude scripts that run your menu, cookie banner, forms and checkout, and test every interactive element after enabling it.

Font handling

Serve fonts from your own domain, limit families and weights, preload only the one or two files used above the fold, and use font-display: swap with metric overrides where your plugin supports them.

LCP fixes specific to WordPress

Find the LCP element in PageSpeed Insights. On WordPress it is usually a hero image, a slider's first slide or a large heading.
Make sure it is not lazy-loaded. Sliders and page builders often lazy-load every image, including the first.
Give it high priority. In a custom theme template, pass the attributes directly:

<?php
echo wp_get_attachment_image(
    get_post_thumbnail_id(),
    'large',
    false,
    array(
        'loading'       => 'eager',
        'fetchpriority' => 'high',
    )
);

Avoid CSS background images for the hero. The browser cannot discover them until the CSS loads. A normal <img> element is found far earlier.
Replace sliders on the home page with a single static image where you can. A slider adds JavaScript and almost always delays LCP.
Reduce render-blocking CSS and JS from plugins that load on every page but are only used on one, such as form or gallery plugins.

Our guide to improving Largest Contentful Paint breaks LCP into its sub-parts if you need to dig deeper.

INP fixes specific to WordPress

INP problems on WordPress usually come from too much JavaScript running on the main thread.

Count your front-end scripts. View source or use the DevTools Network panel filtered to JS. Twenty plugins can easily mean 40 scripts.
Unload plugins where they are not needed. Asset-management plugins (or a few lines of code) can stop contact form, slider and WooCommerce scripts loading on pages that do not use them.
Delay third-party tags: chat, heatmaps, social feeds, video embeds and extra analytics.
Simplify page builder pages. Heavily nested sections and animations add DOM size and event listeners, which slow every interaction.
Check your mega menu, search and filters. Interaction-heavy features built with large libraries are common INP offenders.

For finding the exact slow interaction, follow our guide to fixing Interaction to Next Paint.

CLS fixes specific to WordPress

Images without dimensions. WordPress adds width and height to images inserted through the editor, but images output by some themes, page builders and plugins do not have them. Add the attributes or an aspect-ratio in CSS.
Ads and embeds. Reserve space with a fixed min-height container for ad slots, YouTube embeds and review widgets.
Cookie banners and notification bars. Display them as overlays, not as bars that push the page down after load.
Web font swaps. A fallback font with very different metrics shifts text when the web font arrives. Use metric overrides or a closer fallback.
Content injected by JavaScript, such as "related products" or sticky headers that change height.

See how to fix Cumulative Layout Shift for a step-by-step method.

What to avoid: plugin overlap

Overlapping features are the most common reason a WordPress site gets slower after "optimising".

Overlap	Problem	Fix
Two caching plugins, or plugin cache plus host cache	Stale pages, conflicts, no real gain	Use one page cache
Lazy loading in theme, builder, plugin and core	Hero image lazy-loaded, worse LCP	Keep core's, disable the rest
Two image optimisers	Duplicate WebP files, conflicting markup	Choose one
Minify and combine in two places (plugin plus CDN)	Broken scripts, hard-to-debug errors	Do it in one layer
All-in-one plugin plus single-purpose plugins	Settings fight each other	Turn off duplicated features

Also be wary of "combine all CSS and JS" options. With HTTP/2 and HTTP/3, combining files rarely helps and often breaks things.

Hosting and PHP version

Plugins cannot fix an overloaded server. WordPress.org currently recommends PHP 8.3 or greater and MySQL 8.0+ or MariaDB 10.11+. Older PHP versions are slower and no longer receive security fixes. Check your version in Tools > Site Health > Info > Server, and change it in your hosting control panel (in cPanel, usually MultiPHP Manager or Select PHP Version). Take a backup and test on staging first.

If TTFB stays high with caching enabled, the issue is hosting capacity, not plugins. Our WordPress speed checklist covers choosing and testing hosting.

A sensible order of work

Record the baseline (field and lab) for your key templates.
Update PHP and confirm a single page cache is working.
Optimise images and fix the LCP image's loading and priority.
Defer or delay non-essential JavaScript and unload unused plugin assets.
Fix CLS sources: dimensions, ad slots, banners, fonts.
Remove overlapping features and plugins you no longer need.
Re-test after each step, then watch Search Console for four weeks.

When you have finished, run a free website audit to re-check lab performance alongside titles, meta descriptions, canonicals, image alt text and lazy loading in one scan.

Frequently asked questions

What is the best plugin for WordPress Core Web Vitals?

There is no single best plugin. Most sites need one page cache, one image optimiser and a way to defer or delay non-essential JavaScript. Choose based on which metric is failing and what your host already provides.

Do I need a lazy-loading plugin for WordPress?

Usually not. WordPress has added native lazy loading since version 5.5. Extra lazy-loading plugins often duplicate it and can lazy-load the hero image, which makes LCP worse.

Why did my Core Web Vitals get worse after installing an optimisation plugin?

Common causes are features overlapping with your host or another plugin, the hero image being lazy-loaded, or combined and delayed scripts breaking interactive elements. Disable features one at a time and re-test to find the culprit.

How long until Search Console shows improved Core Web Vitals?

Field data uses a rolling 28-day window, so improvements appear gradually over about four weeks. Use PageSpeed Insights lab data to confirm a fix straight away.

Which PHP version should WordPress use?

WordPress.org recommends PHP 8.3 or greater. Test the upgrade on a staging site first, as old plugins or themes may not be compatible.

WordPress Core Web Vitals: Which Plugins Actually Help

The targets: what "passing" means

Measure before you change anything

What WordPress core already does