The first time I looked at PageSpeed Insights for a page I'd just optimized, it told me two contradictory things at once: a lab score in the 90s, and a field data warning that real users were seeing a much worse experience. Same URL, same three metrics, two different numbers. That gap is the single most common point of confusion with core web vitals, and it's worth untangling before getting into what each metric actually measures.
Part of the confusion is that "core web vitals" gets used as shorthand for three genuinely different things: a loading metric, a responsiveness metric, and a visual stability metric, each with its own failure mode and its own fix. A page can ace one and fail the other two. Treating them as a single "performance score" to chase is how you end up optimizing the wrong thing, shaving 200 milliseconds off a load time that was already fine while a layout shift keeps annoying every mobile visitor.
The three metrics
Largest Contentful Paint (LCP) measures how long it takes the biggest visible element (usually a hero image, a heading, or a large block of text) to render on screen. It's a loading metric: the user is staring at a blank or partial page until this fires. Good is 2.5 seconds or less, needs improvement is up to 4 seconds, and anything beyond that is poor, per web.dev's LCP guide.
Interaction to Next Paint (INP) is the responsiveness metric: from the moment a user clicks, taps, or presses a key, how long until the page visibly responds. Unlike its predecessor, it doesn't stop at the first interaction. It tracks every interaction across the whole page visit and reports something close to the worst one. Good is 200 milliseconds or less, needs improvement up to 500ms, poor beyond that, detailed in web.dev's INP guide.
Cumulative Layout Shift (CLS) is the visual stability metric, tracking how much visible content jumps around unexpectedly as the page loads. Anyone who's tried to tap a button and hit an ad that just loaded in above it instead already knows the feeling. Good is 0.1 or less, needs improvement up to 0.25, poor beyond that, per web.dev's CLS guide. All three thresholds are measured at the 75th percentile of page loads, segmented by device, which matters more than it sounds: it means one in four of your real visits is allowed to run worse than your reported score and you'd still pass.
INP is the newer of the three. It officially replaced First Input Delay as the responsiveness vital on March 12, 2024. FID only measured the delay before an interaction started being processed, which let pages look fast even when the actual response after that delay was sluggish. INP measures the whole round trip, input to next paint, which is why plenty of sites that scored well on FID look worse under INP: it's measuring something FID never did.
Why lab and field data disagree
Lab data comes from a single simulated run: Lighthouse loads your page once, on a fixed network throttle and a fixed device profile, and reports what happened. It's deterministic, repeatable, and completely disconnected from what your actual visitors experience on their actual phones and actual wifi. Field data, by contrast, comes from real visits, aggregated across every user who opted into Chrome's usage statistics, and published in the Chrome User Experience Report (CrUX). CrUX is what Search Console's Core Web Vitals report reads from, and it's what the ranking signal is actually based on.
The gap between them exists because your lab run doesn't know about the visitor on a three-year-old Android phone on a train, and CrUX doesn't isolate for you which specific script caused the slowdown. One important asymmetry: INP genuinely cannot be measured in a lab at all, since Lighthouse's simulated run never performs a real user interaction. Lab tools use Total Blocking Time as a rough proxy instead. If you only ever check lab scores, you're not actually looking at INP, you're looking at a stand-in for it.
Use them for different jobs rather than picking one. Field data tells you whether you have a problem and how bad it is for real visitors, which is the number that actually feeds the ranking signal and the one worth watching over time. Lab data tells you why, by isolating one page load under controlled conditions where you can attribute a slow LCP to one specific request in a waterfall. Debugging from field data alone is like being told your average customer is unhappy with no way to ask a single one of them what went wrong; debugging from lab data alone is like assuming everyone has your test device and your test connection.
What causes bad scores, and how to fix each one
Slow LCP is usually one of: a slow server response before anything can start rendering, render-blocking CSS or JavaScript delaying the paint, or an unoptimized hero image that takes too long to download and decode. Concrete fixes: reduce server response time (caching, a faster origin, or an edge network), preload the LCP image or font with <link rel="preload">, add fetchpriority="high" to the hero image, and make sure nothing above it is lazy-loaded (lazy-loading the LCP element itself is a common self-inflicted regression).
Poor INP almost always traces back to long JavaScript tasks blocking the main thread when an interaction happens, whether that's a heavy event handler, a big re-render, or a third-party script doing work at the worst possible moment. The fix: break long tasks into smaller chunks so the browser can respond to input between them, move non-urgent work off the main thread with a web worker, defer or lazy-load third-party scripts that aren't needed immediately, and avoid expensive synchronous layout work inside event handlers.
High CLS comes from content that doesn't reserve its space before it arrives: images or embeds with no declared dimensions, ads or widgets that resize after they load, and web fonts that render at a different size than their fallback, causing a reflow when the real font swaps in. What helps: always set explicit width and height (or aspect-ratio in CSS) on images and video, reserve space for ads and embeds with a fixed-size container before they load, and choose a fallback font sized close to the real one, or use font-display: optional if a font swap at all is worse than a slightly wrong fallback.
Where this fits in rankings
Core web vitals are part of Google's page experience signals, documented in Google Search Central's guide to understanding core web vitals, and they act more as a tiebreaker than a lever. A fast page with thin, unhelpful content doesn't outrank a slow page that actually answers the query well; relevance still dominates. Where it matters is when two pages are otherwise close on relevance and one loads twice as fast, or when poor CLS is annoying enough that visitors bounce before they read anything, which drags down the engagement signals that do carry more weight. Chasing a perfect vitals score on a page nobody wants to read is optimizing the wrong variable.
How to actually test it
For a single URL, PageSpeed Insights gives you both lab and field data in one report, plus a Lighthouse breakdown of exactly which resource is hurting which metric. For your whole site's real-world field data over time, the CrUX data is queryable directly if you want to track trends rather than check one URL at a time.
Both of those are page-by-page tools, which is fine until you have more than a handful of URLs and want to know whether a slow template is dragging down every page that uses it, not just the one you happened to check. That's where a site-wide crawl earns its keep:
squirrel audit https://example.com --coverage fullsquirrelscan's performance rules run against every crawled page rather than one URL at a time, so a shared layout issue, an unoptimized image component used sitewide, a font loading strategy that regresses every page, shows up as one issue with an occurrence count across every affected page instead of a pile of identical single-page reports you'd have to notice were the same root cause.
If you're chasing a specific regression across a whole site rather than debugging one URL, the lighthouse alternative guide covers running performance checks at that scale in more depth, and the core web vitals checker gives you a fast single-URL read without a full audit. For a broader look at what else a full crawl surfaces beyond performance, the website audit tool runs the same 249+ rules that back everything above. If you're fixing what a crawl turns up from inside an editor, squirrelscan for Cursor covers wiring that loop up directly.