Performance

Core Web Vitals in 2026: The complete checklist for WordPress

EK
Elena K.
Performance Engineer, fluxweb
June 10, 2026
5 min read
1,800 views
Performance analytics dashboard
Last updated: June 10, 2026

We audit somewhere between fifteen and twenty WordPress sites a month, and the pattern hasn't changed in two years: almost every site fails at least one Core Web Vital, and almost every failure traces back to the same handful of causes. This isn't a theoretical checklist — it's the exact sequence we run through on a live audit, in priority order.

If you fix nothing else this quarter, fix these three metrics. They're still the clearest lever you have over both rankings and conversion rate.

TL;DR

LCP problems are almost always image or server-response issues. INP problems are almost always JavaScript issues. CLS problems are almost always missing dimensions on late-loading content. Fix in that order — LCP, then INP, then CLS.

1. Why Core Web Vitals still decide rankings in 2026

Google folded Core Web Vitals fully into its page experience ranking signal back in 2021, and nothing since has walked that back — if anything, the bar has risen as more of the web has gotten faster and the relative penalty for being slow has grown sharper. On top of the ranking impact, our own conversion data across client sites shows a near-linear relationship between LCP and checkout completion rate below the 2.5 second mark.

The metrics themselves also matter for a more basic reason: they're a decent proxy for "does this site feel broken." A slow LCP feels like a site that hasn't loaded. A bad INP feels like a site that isn't responding. Bad CLS feels like a site fighting you as you try to read it. Fixing them isn't just an SEO exercise.

91%
Of audited sites fail at least one vital
2.5s
LCP threshold for "Good"
200ms
INP threshold for "Good"

2. LCP: getting under 2 seconds on real WordPress hosting

Largest Contentful Paint is almost always one of three things on WordPress: an unoptimised hero image, slow server response (TTFB), or render-blocking CSS/JS above the fold. We check all three, in this order:

  1. Is the LCP element an image? If so, is it served in a modern format (WebP/AVIF), correctly sized for its container, and marked with fetchpriority="high" instead of lazy-loaded?
  2. What's TTFB? Anything over 600ms usually means no object cache, a bloated plugin stack, or under-provisioned hosting. Object caching (Redis or Memcached) is the single highest-leverage fix we make here.
  3. Is critical CSS inlined, or is the browser waiting on a full stylesheet before it can paint anything?

"We fixed LCP on a client's homepage from 4.8s to 1.9s with three changes: WebP hero images, Redis object cache, and moving Google Tag Manager to load after first paint. No redesign, no new hosting."

— Elena K., Performance Engineer

3. INP: the metric killing WordPress sites right now

Interaction to Next Paint is where most of our audits find the worst scores, and it's rarely obvious why until you profile it. The usual suspects: page builder JavaScript that re-renders more of the DOM than necessary on interaction, third-party scripts (chat widgets, analytics, ad tech) blocking the main thread, and heavy event listeners attached to elements that don't need them.

Quick fix checklist

Audit your plugins with Query Monitor · defer every non-critical script · replace heavy contact-form plugins with lightweight alternatives · lazy-load all below-fold content · move Google Tag Manager to fire after interaction, not on load.

The fix that moves the needle most often isn't clever — it's deletion. Every plugin you remove that isn't earning its keep is JavaScript that isn't blocking the main thread. We've seen INP improve by 150ms+ just from consolidating four overlapping SEO/analytics plugins into one.

functions.php — defer non-critical scripts
// Defer everything except the handles you explicitly need on load function fluxweb_defer_scripts( $tag, $handle ) { $critical = array( 'jquery-core' ); if ( in_array( $handle, $critical, true ) ) { return $tag; } return str_replace( ' src', ' defer src', $tag ); } add_filter( 'script_loader_tag', 'fluxweb_defer_scripts', 10, 2 );

4. CLS: the layout shift culprits nobody checks

Cumulative Layout Shift is the easiest of the three to fix and the one we see neglected most. It's almost always one of: images without explicit width/height attributes, web fonts causing a flash of unstyled text that reflows the page, ads or embeds injected without a reserved slot, or a cookie banner that pushes content down after render.

The fix is mechanical: reserve space for everything that loads asynchronously. Set explicit dimensions on every image and iframe, use font-display: optional or preload critical fonts, and give every dynamically injected element (cookie banners, chat widgets, ad slots) a fixed-height container from the start.

5. The complete audit checklist

Here's the full sequence we run, in order of expected impact. Most sites see the biggest single jump from the first two items alone.

  1. Enable server-side object caching (Redis/Memcached) — biggest lever on TTFB and LCP.
  2. Convert and correctly size all images to WebP/AVIF, with explicit dimensions.
  3. Audit installed plugins with Query Monitor and remove or replace anything with heavy main-thread JavaScript.
  4. Defer or async every non-critical script, including analytics and chat widgets.
  5. Inline critical CSS and defer the rest.
  6. Reserve space for every async-loaded element (fonts, embeds, banners).
  7. Re-test with PageSpeed Insights and the Chrome UX Report field data, not just lab data — field data is what actually feeds rankings.
EK
Elena K.
Performance Engineer, fluxweb
Leads performance audits at fluxweb — Core Web Vitals, server response times, and the unglamorous plugin archaeology that usually turns out to be the real bottleneck.