WordPress Core Web Vitals — LCP, INP, CLS Guide

What are Core Web Vitals? Core Web Vitals (CWV) are Google’s three metrics for real-world page experience: LCP (Largest Contentful Paint — how fast the main content renders), INP (Interaction to Next Paint — how responsive the page feels), and CLS (Cumulative Layout Shift — how visually stable the page is). Google uses CWV as a ranking signal and reports them in Search Console.

What are the “good” thresholds?

Field data vs lab data — what’s the difference? Lab data is what tools like Lighthouse and PageSpeed Insights synthesise in a controlled test environment. Field data is what real users actually experience on your site (collected via the Chrome User Experience Report). Google ranks on field data, not lab data. A site with perfect Lighthouse scores but slow real-user performance still ranks poorly. Always check field data — Asteris’s Performance module surfaces this via the CrUX API.

LCP (Largest Contentful Paint) — under 2.5s

LCP measures how fast the largest visible element renders. Usually a hero image, large heading, or above-the-fold video.

How to improve LCP

  1. Add fetchpriority="high" to the LCP image. Explicitly tells the browser this image is the most important. Asteris Performance does this automatically.
  2. Preconnect to image CDN domains. <link rel="preconnect" href="https://cdn.example.com"> shaves DNS+TCP+TLS time off the LCP image fetch.
  3. Compress LCP image aggressively. A 200 KB hero image is fine; a 2 MB one is not. WebP and AVIF formats are 30-50% smaller than JPEG.
  4. Don’t lazy-load the LCP image. Lazy loading defers fetch until the image is near the viewport — but LCP is in the initial viewport. Lazy-loading the LCP image actively hurts LCP.
  5. Serve from a fast CDN. Cloudflare, Bunny, KeyCDN. Origin-only delivery is slow for distant users.
  6. Inline critical CSS. If your LCP element requires CSS to render, blocking CSS fetch delays LCP. Inline the critical CSS (above-the-fold styles) in <head>.
  7. Use Early Hints (103) if your host supports it. Pushes a preload signal before the main response arrives.

INP (Interaction to Next Paint) — under 200ms

INP measures how fast the page responds to user interactions (clicks, taps, key presses). Replaces the older FID (First Input Delay) metric as of March 2024.

How to improve INP

  1. Reduce JavaScript on the main thread. Long-running JS blocks event handling. Use requestIdleCallback, web workers, or simply less JS.
  2. Defer non-critical scripts. <script defer> or <script async> so they don’t block during user interaction.
  3. Code-split. Don’t load all your JS up front; load what’s needed for the initial view, lazy-load the rest.
  4. Avoid synchronous third-party scripts. Analytics tags, chat widgets, ad scripts — defer or async all of them.
  5. Watch out for jQuery-heavy themes. Many older WordPress themes load jQuery synchronously and bind heavy handlers; this kills INP on mid-range mobile.
  6. Reduce DOM size. A page with 5000 elements is slower to lay out and respond to than a page with 500. Cut DOM complexity where possible.

CLS (Cumulative Layout Shift) — under 0.1

CLS measures how much visible content shifts position during page load. Caused by images without dimensions, ads loading into existing space, web fonts swapping after page paint.

How to improve CLS

  1. Always specify image dimensions. <img src="..." width="800" height="600"> reserves space before the image loads, preventing shift.
  2. Reserve space for ads and embeds. If an ad slot will be 300x250, set a placeholder div with those exact dimensions.
  3. Use font-display: swap or font-display: optional carefully. swap causes a flash of unstyled text but no shift if font metrics match. Use size-adjust to match font metrics tightly.
  4. Avoid dynamically injected content above existing content. Cookie banners, top-of-page promotions inject elements and push everything down — major CLS contributor.
  5. Animate with transform, not layout properties. transform: translate() doesn’t cause layout shift; top / left / width / height do.

How to measure WordPress Core Web Vitals

Field data (real users)

Lab data (synthesised tests)

Always compare lab to field. Big gaps mean your lab environment doesn’t match real users — typically your real users are on slower devices or networks than your test machine.

Frequently asked questions

What are the Core Web Vitals thresholds in 2026? LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1 — all measured at the 75th percentile of real users (field data).

Does WP Rocket fix Core Web Vitals? WP Rocket helps but doesn’t guarantee good CWV. Caching and asset optimization improve LCP and INP; CLS is mostly a content + theme issue that caching doesn’t fix. Asteris Performance → ships modern techniques (fetchpriority on LCP, Speculation Rules, Early Hints) that go beyond WP Rocket’s default profile.

How do I find my LCP element? Open Chrome DevTools → Performance → Record a page load → look for “Largest Contentful Paint” in the timing. Or use PageSpeed Insights — it identifies the LCP element automatically.

What’s the difference between field data and lab data? Field data is real users’ experience (Chrome UX Report). Lab data is synthesised in a controlled test (Lighthouse). Google ranks on field data. Lab data is useful for debugging but not the final answer.

Why is my INP suddenly worse than my old FID? INP measures all interactions, not just the first one (FID). If your page is slow on the 10th click, FID missed it; INP catches it. Most sites’ INP is worse than their FID was — that’s expected, not a regression.

Performance module → · Asteris vs WP Rocket →