Core Web Vitals are the three metrics Google uses to put a number on how a page feels to a real visitor: how fast the main content shows up, how quickly the page reacts when you tap or click, and whether things jump around while it loads. If you run a WordPress site, they are also the most concrete, fixable performance target you have — and unlike a vague Lighthouse score, Google judges them on data from actual humans, not a lab simulation.

This guide defines each metric precisely, explains why they matter beyond SEO, and — because this is a WordPress site — walks through the specific plugins, settings, and trade-offs that move each number.

The three metrics, defined

As of March 2024, Core Web Vitals are LCP, INP, and CLS. If you read an older guide that lists First Input Delay (FID), that metric was retired — INP replaced it. Anything still calling FID a Core Web Vital is out of date.

Largest Contentful Paint (LCP) — loading

LCP measures how long it takes for the largest visible element in the viewport — usually a hero image, a heading, or a background — to render. It is the closest single number to "when does this page look loaded?"

Good: under 2.5 seconds
Needs improvement: 2.5s to 4.0s
Poor: over 4.0 seconds

Interaction to Next Paint (INP) — responsiveness

INP measures how quickly the page visually responds to user interactions — taps, clicks, key presses — across the entire visit, not just the first one. It captures the lag between you doing something and the screen actually updating. High INP is what makes a page feel sluggish or "stuck" even after it has loaded.

Good: under 200 milliseconds
Needs improvement: 200ms to 500ms
Poor: over 500 milliseconds

Cumulative Layout Shift (CLS) — visual stability

CLS is a unitless score for how much content unexpectedly jumps around as the page loads. You have felt this: you go to tap a link and an ad or image loads above it, shoving the link down, and you tap the wrong thing. Lower is better.

Good: under 0.1
Needs improvement: 0.1 to 0.25
Poor: over 0.25

Why you should actually care

Two reasons, in order of honesty.

First, user experience and revenue. Slow, janky pages drive people away before they convert. A visitor who waits four seconds for your hero image, then mis-taps a shifted button, is a visitor you are about to lose. This is the real payoff, and it exists whether or not Google ever looked at your site.

Second, SEO. Core Web Vitals are a ranking signal inside Google's page-experience signals. They matter — but keep the weight honest: relevance and content quality dominate rankings, and CWV act more as a tiebreaker between comparable pages than as a top lever. Don't gut your content strategy chasing a perfect 100. Do fix a genuinely "poor" rating, because that is both a ranking drag and a sign real users are suffering.

Field data vs. lab data — where you get judged

This is the distinction that trips most people up. Google assesses your site on field data: real measurements from Chrome users, aggregated in the Chrome User Experience Report (CrUX), evaluated at the 75th percentile. In plain terms, three out of four real visits must hit the "good" threshold for you to pass.

The score you see in a tool like Lighthouse or the top of PageSpeed Insights is usually lab data — a single simulated load on a throttled connection. It is great for debugging because it is repeatable, but it is not what Google ranks on. You can have a glorious lab score and still fail in the field if your real users are on mid-range phones and patchy mobile networks.

Where to look at the real numbers:

PageSpeed Insights — the "Discover what your real users are experiencing" panel at the top is field data; the diagnostics below are lab.
Google Search Console → Core Web Vitals report — your whole site's field status, grouped by URL pattern, split by mobile and desktop. This is the report to trust.

Fixing each metric on WordPress

The fixes differ per metric, so target the one that is actually failing rather than installing five plugins and hoping.

Improving LCP

LCP problems on WordPress almost always trace to slow server response (TTFB) or a heavy hero image.

Hosting and TTFB: aim for a TTFB under ~600ms. Cheap shared hosting is the most common culprit. Managed hosts like Kinsta, Cloudways, or SiteGround, with server-level caching, move this number more than any plugin can.
Page caching: serve cached HTML instead of rebuilding pages per request. WP Rocket, FlyingPress, or LiteSpeed Cache (free, if your host runs LiteSpeed) all do this well.
Image format and priority: serve your hero in WebP or AVIF, size it correctly, and let it load eagerly — modern optimizers add fetchpriority="high" to the LCP image so the browser fetches it first.
CDN: Cloudflare or BunnyCDN puts assets physically closer to visitors and trims latency.

Improving INP

INP is the JavaScript metric, and on WordPress that usually means too much script from page builders and plugins.

Audit the plugin load: heavy page builders (Elementor, Divi) and a long plugin list pile up main-thread work. Perfmatters lets you disable specific scripts on pages that don't need them.
Defer and delay non-critical JS: "delay JavaScript until interaction" (in WP Rocket, Perfmatters, or FlyingPress) holds back analytics, chat widgets, and tracking until the user actually engages, freeing the main thread.
Tame third-party scripts: chat bubbles, ad networks, and embedded videos are frequent INP offenders. Load them lazily or only where needed.

Improving CLS

CLS is the cheapest to fix and the easiest to break with a careless edit.

Always set image dimensions: width and height attributes reserve space so nothing shifts when the image arrives. WordPress adds these automatically — broken themes that strip them are a common cause.
Reserve space for embeds and ads: give ad slots, iframes, and embeds a fixed container so late-loading content doesn't shove the page down.
Handle web fonts carefully: font-display: swap avoids invisible text, but a big metric mismatch between fallback and web font can itself cause a shift — preload critical fonts to minimize it.

The short version

Core Web Vitals are LCP (loading, under 2.5s), INP (responsiveness, under 200ms), and CLS (stability, under 0.1), graded on real-user data at the 75th percentile. Check your standing in Search Console, fix whatever is genuinely "poor," and remember the point isn't a green badge — it's a site that loads fast, responds instantly, and doesn't move under your visitors' fingers.

What Are Core Web Vitals and Why Should You Care?