← All articles

How to Fix Core Web Vitals on WordPress (2026)

WordPress sites fail Core Web Vitals for a short, predictable list of reasons: a heavy theme, too many plugins, render-blocking CSS and JavaScript, slow server response on cheap shared hosting, and unoptimised images. Fix them in that rough order and most sites pass. The catch most guides skip is that a caching plugin, the usual first move, can only address part of that list. The rest is structural.

About 45 percent of mobile pages across the web have good Core Web Vitals, according to the 2025 HTTP Archive Web Almanac. WordPress sites, as a group, sit below that average, and not because of WordPress itself. It is what gets bolted onto it.

Why WordPress specifically struggles

WordPress core is lean. The performance problems arrive with the ecosystem that makes WordPress appealing in the first place: themes that do everything, plugins for every feature, and page builders that trade clean markup for drag-and-drop convenience.

Four things do most of the damage:

  • The theme sets a ceiling. A bloated multipurpose theme ships a large payload of CSS, JavaScript, and fonts before a single word of your content loads. A 500KB theme versus a 50KB one is a tenfold handicap you carry on every page, and no plugin fully undoes it.
  • Plugin sprawl. The average site runs 20 to 30 plugins, and many load their own CSS and JavaScript on every page, including pages where they do nothing. Installing a seventh plugin to fix the problems caused by the previous six is a popular strategy and a losing one.
  • Shared hosting and slow server response. On cheap shared plans your site competes for CPU and memory with hundreds of others, which inflates Time to First Byte. You cannot optimise your way out of a slow server, and TTFB feeds straight into your LCP.
  • Unoptimised images. WordPress does not compress or correctly size uploads by default, so editors drop in full-resolution photos that become the heaviest thing on the page.

You can see how your own stack compares in the HTTP Archive Core Web Vitals Technology Report, which breaks pass rates down by platform.

The fix order that actually works

Work top-down. Each step removes a bottleneck that would otherwise mask the next one.

  1. Fix server response first. Aim for a Time to First Byte under 800ms. If you are on overloaded shared hosting, the highest-impact change you can make is moving to decent managed WordPress hosting. This is the one fix no plugin can deliver.
  2. Cut theme and plugin weight. Audit what you run. Remove plugins you do not use, replace a heavy multipurpose theme with a lighter one, and be honest about which page-builder features you actually need. This is the structural work, and it is where the biggest, most durable wins live.
  3. Optimise images. Compress them, serve modern formats like WebP or AVIF, size them to their display dimensions, and set explicit width and height so they do not shift the layout. An image plugin handles most of this automatically.
  4. Eliminate render-blocking CSS and JavaScript. Now a caching and optimisation plugin earns its place: page caching, minification, deferring non-critical JavaScript, and generating critical CSS. This is the part of the list a plugin genuinely fixes.
  5. Tackle INP last. If interactions feel sluggish, the cause is almost always third-party and plugin JavaScript running long tasks on the main thread. The fixes are the same on WordPress as anywhere else: see how to fix INP.

What a plugin can and cannot fix

A caching plugin like the popular all-in-one options is genuinely useful, but it is paracetamol, not surgery. It is worth being clear about the line, because betting your Core Web Vitals on a single plugin is the most common WordPress mistake.

A plugin can fixA plugin cannot fix
Page cachingA slow shared host (TTFB)
Minifying CSS and JSA 500KB multipurpose theme
Deferring non-critical JavaScriptPlugin sprawl loading on every page
Lazy-loading and compressing imagesRender-blocking baked into the theme itself
Generating critical CSSBloated page-builder markup

The right-hand column is structural. It lives in your theme, your plugins, and your host, and it is the work that needs decisions, not just a settings toggle.

How to check whether you actually pass

Use field data, not a one-off lab score. Open the Core Web Vitals report in Google Search Console, which reads from real Chrome user data and groups your URLs as good, needs improvement, or poor. A green Lighthouse run on your laptop can look fine while real visitors on mid-range phones quietly fail, and Lighthouse cannot measure INP at all.

One more thing worth knowing: that field data is a rolling 28-day average, so a fix you ship today will not show up for several weeks. Make the change, then give it time before deciding it did not work. And do not waste energy chasing rumoured threshold changes; the targets have not moved.

The takeaway

WordPress does not fail Core Web Vitals because it is WordPress. It fails because of a heavy theme, too many plugins, a slow host, and oversized images, in roughly that order of impact. A plugin handles the caching-and-deferral layer; the structural causes underneath it need real decisions about your theme, your plugins, and where the site is hosted.

No developer to make those changes? That is a normal place to be, and exactly the kind of thing an audit untangles: which of those five causes is actually costing you, ranked by effort against impact, so you fix the things that move the numbers and skip the things that do not.

Frequently asked questions

Why do WordPress sites fail Core Web Vitals so often?

Not because of WordPress core, which is lean, but because of what gets added to it: a heavy multipurpose theme, plugin sprawl (the average site runs 20 to 30 plugins), render-blocking CSS and JavaScript, slow server response on cheap shared hosting, and unoptimised images. Across the web about 45 percent of mobile pages have good Core Web Vitals, and WordPress sites as a group sit below that average.

Will a caching plugin fix my Core Web Vitals?

Partly. A caching and optimisation plugin handles page caching, minification, deferring non-critical JavaScript, lazy-loading images, and critical CSS. It cannot fix the structural causes underneath: a slow shared host, a bloated theme, plugin sprawl, or render-blocking baked into the theme itself. Treat it as one part of the fix, not the whole fix.

What should I fix first on a slow WordPress site?

Work top-down: server response (Time to First Byte, ideally under 800ms, which usually means better hosting) first, then theme and plugin weight, then images, then render-blocking CSS and JavaScript, and finally INP from third-party and plugin scripts. Each step removes a bottleneck that would otherwise mask the next.

Do I need a developer to pass Core Web Vitals on WordPress?

Some fixes are configuration: installing a caching plugin, compressing images, or moving to better hosting. The deeper structural fixes (replacing a heavy theme, removing render-blocking code, reducing INP) often need code-level work. An audit identifies which of the causes is actually costing you and how much effort each fix takes, so you can decide what to do yourself and what to hand off.

Want this done for you and verified against real field data?

Book an audit