Core Web Vitals for WordPress

What real WordPress sites measure

To ground this guide in current data, we measured two well-known WordPress sites with Lighthouse 13 (mobile emulation) in July 2026. TechCrunch — WordPress at news-publisher scale — scored 50/100: LCP came in at 3.8 s, over the 2.5 s threshold, and Total Blocking Time at a heavy 3,896 ms, almost entirely third-party ad and analytics scripts rather than WordPress itself. Matt Mullenweg’s own blog ma.tt — WordPress with a lean theme and a light plugin load — scored 82/100 with LCP at 3.5 s, TBT at just 288 ms, and CLS of 0.05. The spread illustrates the thesis of this guide: the platform is the same; the stack on top decides the score. A lean WordPress build sits one image optimization away from green Core Web Vitals; an ad-loaded one has a JavaScript problem no cache plugin can fix.

Caching first: page cache, then object cache

Uncached WordPress rebuilds every page in PHP on every request — theme templates, plugin hooks, and a stack of database queries before a single byte reaches the visitor. A full-page cache short-circuits all of it. WP Rocket and W3 Total Cache do this at the plugin level; LiteSpeed Cache does it at the server level if your host runs LiteSpeed; managed hosts like Kinsta and WP Engine bake it into their nginx layer. Whichever you pick, the effect is the same: TTFB drops from 600-1200ms to under 200ms, and every metric that starts after TTFB (FCP, LCP) inherits the gain.

If your site is dynamic — WooCommerce carts, membership plugins, logged-in users — page cache hit rates fall, and a persistent object cache becomes the second lever. Redis via the Redis Object Cache plugin keeps repeated queries (options, term lookups, WooCommerce sessions) out of MySQL. Confirm it is actually connected under Tools → Site Health; a surprising number of sites install the plugin and never enable the drop-in.

Images: modern formats, correct sizes, and the LCP hero

The LCP element on most WordPress pages is the featured image or hero, and the default is to serve it as an oversized JPEG. Fix the format first: the official Performance Lab plugin (from the WordPress core performance team) converts uploads to WebP or AVIF at upload time, and ShortPixel or Imagify bulk-convert the existing media library. Modern formats typically cut image bytes 30-70% with no visible difference.

Then fix delivery. WordPress 6.3+ automatically adds fetchpriority="high" to the image it believes is the LCP candidate — but page builders and sliders often defeat the heuristic. If your hero is rendered by Elementor, Divi, or a slider plugin, check the HTML: the LCP image should load eagerly with high priority while everything below the fold keeps the default lazy loading WordPress has applied since 5.5. Replacing a slider with a static hero image is routinely worth 1-2 seconds of mobile LCP on its own.

The plugin tax and render-blocking assets

Every active plugin can enqueue CSS and JavaScript on every page, whether the page uses it or not — a contact-form stylesheet on your homepage, slider JS on your blog posts. Install Query Monitor and look at what each request actually loads and which hooks are slow. Then either remove the plugin, or keep it and stop it loading globally: Perfmatters and Asset CleanUp both let you dequeue specific scripts per page or post type.

What remains should not block rendering. WP Rocket’s “Load JavaScript deferred” and “Remove Unused CSS”, or Autoptimize’s critical-CSS path, move theme and plugin assets out of the critical rendering path so first paint happens before the full stylesheet payload arrives. Re-test after each change — on plugin-heavy sites Total Blocking Time drops almost linearly as you remove or defer scripts. Page builders deserve special mention: Elementor and Divi pages carry deep DOM trees and their own runtime; the block editor with a lightweight theme like GeneratePress or Kadence produces the same layout at a fraction of the cost.

Hosting, PHP versions, and TTFB

Optimization has a floor set by your server. If TTFB stays above ~500ms with a page cache active and hitting, the bottleneck is the host, not WordPress. Three checks before you migrate: PHP version (8.3 is roughly twice as fast as the 7.x versions still common on legacy shared hosting — switchable in cPanel), OPcache enabled, and whether your “cloud” plan is actually an oversold shared box.

A CDN completes the picture. Cloudflare’s free tier caches static assets globally; Cloudflare APO ($5/month) goes further and caches the HTML itself at the edge, which is effectively a worldwide page cache — international visitors stop paying transatlantic latency on every page view. For sites with a geographically concentrated audience, a good origin close to that audience achieves the same thing for free.

Measuring WordPress correctly

The classic WordPress measurement mistake is testing while logged in: the admin bar and per-user cache bypass mean you are measuring the uncached experience your visitors never see. Always test in a private window, and run the test twice — the first run may prime a cold cache, the second shows what a typical visitor gets.

Test more than the homepage. Archive pages, WooCommerce category pages, and search results have different query patterns and often miss the page cache. And separate lab from field: a lab test (like RankVitals or PageSpeed Insights) diagnoses the mechanics, but Google evaluates Core Web Vitals from Chrome field data collected over 28 days — after a fix ships, expect the field numbers to take about a month to reflect it.