Core Web Vitals: What LCP, INP, and CLS Actually Measure

A page can load in under a second and still feel slow. Maybe the main content pops in fast, but the page keeps shifting around for another two seconds while ads and fonts load in behind it. Maybe everything looks ready, but tapping a button does nothing for half a second because the browser's still busy running scripts. "Slow" isn't one thing, and for years there wasn't a clean way to measure the specific ways a page can feel bad to use.

Core Web Vitals is Google's answer to that: three specific, measurable metrics that each capture a different way a page can go wrong. Not page weight, not server response time in isolation, but the actual experience of loading, interacting with, and reading a page. They matter for two overlapping reasons: they're a real ranking signal in Google Search, and they're a genuinely useful way to know whether your site actually feels fast, not just whether a lab test says it does.

The Three Metrics

Largest Contentful Paint (LCP) measures loading: how long it takes for the biggest visible element, usually a hero image, a heading, or a large block of text, to render on screen. Google's published thresholds: 2.5 seconds or less is good, over 4 seconds is poor, with everything in between needing improvement.

Interaction to Next Paint (INP) measures responsiveness: how long the page takes to visually respond after someone clicks, taps, or types. This replaced First Input Delay (FID) as an official Core Web Vital in March 2024, because FID only measured the delay before the first interaction, while INP tracks responsiveness across every interaction during the page's lifetime, a much more honest picture. Thresholds: 200 milliseconds or less is good, over 500 milliseconds is poor.

Cumulative Layout Shift (CLS) measures visual stability: how much visible content unexpectedly moves around as the page loads. This is the metric behind the classic frustration of a page loading, you start reading, and then an ad or image loads in above what you were looking at and shoves everything down. Thresholds: 0.1 or less is good, over 0.25 is poor.

What Usually Breaks Each One

LCP is usually broken by: a slow server response before anything can start rendering, render-blocking CSS or JavaScript that delays the page from painting anything, an unoptimized hero image that's far larger than it needs to be, or content that only appears after client-side JavaScript finishes running instead of being present in the initial HTML.

INP is usually broken by: long JavaScript tasks that block the browser's main thread, so it can't respond to input even though the page looks interactive. Heavy third-party scripts (analytics, chat widgets, ad tech) are common culprits, since they often run expensive code without the site owner realizing it. Large, unoptimized JavaScript bundles that take a long time to parse and execute have the same effect.

CLS is usually broken by: images or embeds rendered without explicit width and height, so the browser doesn't reserve space for them and the layout jumps once they load. Web fonts that swap in after a fallback font has already rendered, shifting text as it reflows. Content, most often ads, injected dynamically above existing content instead of into space that was already reserved for it.

Lab Data vs. Field Data

There are two different ways these metrics get measured, and mixing them up causes a lot of confusion. Lab data comes from a simulated test run in a controlled environment, tools like Lighthouse run the page once, on a fixed device and network profile, and report what happened. Field data comes from real users, actual visitors on their actual devices and networks, aggregated over time (Google calls this the Chrome User Experience Report, or CrUX).

A page can score well in a lab test and still perform poorly for real users, because lab tests don't account for real network conditions, real device performance (a lot of mobile traffic comes from mid-range phones, not the machine running the test), or the actual mix of pages people land on. Field data is what Google actually uses for the ranking signal. Lab data is useful for debugging a specific page before or after a change, but it's not the same measurement, and a passing lab score doesn't guarantee a passing field score.

How to Check Your Own Site

For field data: Google Search Console's Core Web Vitals report shows real aggregated data for your actual traffic, grouped by URL and by whether each metric is good, needs improvement, or poor. PageSpeed Insights also shows field data when enough real-user data exists for that page.

For lab data: run PageSpeed Insights or Lighthouse (built into Chrome DevTools) against a specific URL. This is the right tool for testing a page before it ships, or diagnosing why a specific page is slow, since it gives you a detailed breakdown of what's contributing to each metric, not just the final number.

Checking a single page isn't usually enough. A site-wide crawl that runs this kind of audit across every page, not just the homepage, catches the pages that never show up in a spot check, an old blog post with an unoptimized hero image, a checkout page loaded down with third-party scripts, a product page where every image is missing its dimensions.

Why This Isn't Just an SEO Metric

It's easy to treat Core Web Vitals as something to optimize purely because Google says so, but the underlying thing being measured is real regardless of the ranking impact: does the page load fast, respond quickly, and stay visually stable. A site can rank fine today and still be quietly losing conversions because checkout feels sluggish, or losing readers because the article jumps around while they're trying to read the first paragraph. The ranking signal is a reason to care sooner. The actual experience is the reason to care at all.

Final Thoughts

Core Web Vitals turn a vague complaint, "this site feels slow", into three specific, measurable things: does the main content show up quickly, does the page respond when you interact with it, and does it hold still while you're trying to read it. Each one has a clear cause and a clear fix, which is what makes them useful beyond just a ranking checkbox.

The real trap is testing one page in a lab tool, seeing a good score, and assuming the rest of the site is fine. Real users hit real pages on real networks, and a site-wide check across every page is the only way to know whether the experience actually holds up where it counts.