Core Web Vitals explained: what PageSpeed actually measures
"Make your site faster" is useless advice without a definition of fast. Core Web Vitals are Google's attempt at that definition: three specific, measurable things about how a page feels to load and use. They feed into search ranking, they're what the PageSpeed Insights API measures, and they line up with what actually makes visitors stay or bounce.
Our performance check runs against Google's PageSpeed Insights (it appears when a PSI key is configured), so it's reporting the same numbers Google itself uses.
The three metrics, in plain English
LCP, Largest Contentful Paint. How long until the biggest thing on screen (usually the hero image or headline) has loaded. This is the "is it there yet?" metric. Good is under 2.5 seconds.
INP, Interaction to Next Paint. When someone taps or clicks, how quickly the page visibly responds. This is the "does it feel snappy or stuck?" metric (it replaced the older FID in 2024). Good is under 200 milliseconds.
CLS, Cumulative Layout Shift. How much the page jumps around as it loads: the maddening moment when you go to tap a button and an ad shoves it down. This is the "does it hold still?" metric. Good is under 0.1.
Together they cover loading, interactivity, and stability, the three ways a page can feel slow or broken even when it technically "works."
Why they matter
Two reasons, and the second is the real one:
- Ranking. Core Web Vitals are a confirmed Google ranking signal. All else equal, a faster, more stable page has an edge.
- Behavior. People abandon slow pages. Every fraction of a second of delay costs you visitors, conversions, and patience. And for AI answer engines, a page that's too slow to fetch reliably is a page that's harder to use as a source. The ranking effect is modest; the bounce effect is not.
Lab vs. field data
One thing that trips people up: PageSpeed shows two kinds of numbers.
- Field data is real Core Web Vitals from actual Chrome users on your site over the last 28 days. This is what Google uses for ranking. It only exists once you have enough traffic.
- Lab data is a single simulated load in a controlled environment. It's reproducible and great for debugging, but it's not what ranks you.
When they disagree, trust field data for "how am I really doing" and lab data for "what should I fix."
Where to start
You don't have to chase a perfect 100. Aim for "good" on all three and stop obsessing. The highest-impact fixes, roughly in order:
- Optimize your largest image (helps LCP). Compress it, serve modern formats (WebP/AVIF), size it correctly, and don't lazy-load the hero.
- Reserve space for images, ads, and embeds (helps CLS). Set explicit width/height or aspect-ratio so nothing shifts when they load.
- Cut and defer heavy JavaScript (helps INP and LCP). Unused scripts are the usual culprit behind a sluggish page.
- Compress and cache your assets, which ties directly into compression and page weight.
Those last two are their own checks for a reason: they're the foundation a fast page is built on.
Common mistakes
- Chasing a perfect lab score while ignoring the field data that actually ranks you.
- An enormous, uncompressed hero image tanking LCP.
- Ads and embeds with no reserved space, causing layout shift.
- Shipping a pile of JavaScript the page doesn't need, hurting interactivity.
- Treating performance as one-and-done. It regresses every time you add a script or a heavy embed, so re-check periodically.
FAQ
What are good Core Web Vitals scores?
LCP under 2.5s, INP under 200ms, CLS under 0.1. Hit "good" on all three and you're in solid shape.
What happened to FID?
First Input Delay was replaced by Interaction to Next Paint (INP) in 2024. INP is a more complete measure of responsiveness across the whole visit rather than only the first interaction.
Do Core Web Vitals really affect rankings?
Yes, they're a confirmed ranking signal, though a modest one next to relevance and content. The bigger payoff is fewer people bouncing off a slow page.
Why is my lab score great but field data poor (or vice versa)?
Lab is one simulated load; field is real users on varied devices and networks. Field data is what Google ranks on; use lab data to debug.
Key Takeaways
- Core Web Vitals are three metrics: LCP (loading), INP (interactivity), and CLS (visual stability). Good thresholds are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.
- INP replaced First Input Delay (FID) in 2024 and measures responsiveness across the whole visit instead of only the first interaction.
- Field data reflects real Chrome users over the last 28 days and is what Google uses for ranking; lab data is a single simulated load useful for debugging.
- The highest-impact fixes are optimizing the largest image for LCP, reserving space for images and embeds for CLS, and cutting or deferring heavy JavaScript for INP.
- Core Web Vitals are a confirmed Google ranking signal, but the larger payoff is reduced bounce, since people abandon slow pages.
Want your Core Web Vitals pulled straight from PageSpeed, alongside the rest of your technical health? Run a free audit. More in the Technical explainers.
Related articles
- Technical
Text compression (gzip, Brotli, zstd): the easiest speed win
Compression can cut what you send over the wire by two-thirds, and it's often a single setting. Here's what gzip, Brotli, and zstd do, and how to switch one on.
Read article →
- Technical
HTML page weight: why a bloated document slows everything down
Before a single image loads, the browser has to download and parse your HTML. If that document is a megabyte of markup, everything starts slow. Here's how to slim it.
Read article →
- Technical
The mobile viewport meta tag: one line that makes your site mobile-friendly
Without one meta tag, phones show your site as a tiny, zoomed-out desktop page. With it, your responsive design actually works. Here's the line and why it matters.
Read article →