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

You've probably seen "Core Web Vitals" flagged in Search Console with no real explanation of what's wrong. Here's Core Web Vitals explained the way I explain it to clients: not as a compliance checkbox, but as three specific measurements of what a visitor experiences when your page loads. Get the terminology straight first, because the fixes only make sense once you know what each number is actually counting.

What Core Web Vitals actually measures

Largest Contentful Paint (LCP) times how long it takes the biggest visible element on the page to finish rendering. Usually that's a hero image, a headline, or a banner. Google picks the largest element because it's the thing a visitor is most likely waiting on before they consider the page loaded.

Interaction to Next Paint (INP) replaced First Input Delay in 2024. It measures the time between a visitor's click, tap, or keypress and the moment the browser visually responds. INP samples every interaction during a visit and reports something close to the worst one, not the average, which is why a single laggy dropdown menu can drag down your score even if the rest of the page is fast.

Cumulative Layout Shift (CLS) measures how much visible content moves after it has already rendered. An ad that loads late and pushes the paragraph you were reading down the page counts as a layout shift. A web font that swaps in and resizes your heading counts too. CLS adds every unexpected movement into a single score for the page.

Why Google uses these specific numbers

None of these three metrics is arbitrary. Each one maps to a moment where a real visitor gets frustrated: waiting for content to appear, tapping a button that doesn't respond, or losing their place because the page jumped underneath them. Google built Core Web Vitals from actual Chrome user data, the same data that populates the CrUX report, rather than from lab simulations. That's why fixing a score in a testing tool doesn't always match what your real visitors experience.

That distinction matters more than most guides admit. Lighthouse and PageSpeed Insights run a single simulated page load on a fixed connection speed. Your real Core Web Vitals score, the one that affects search, comes from aggregated data across your actual visitors on their actual devices and connections. A site can pass every lab test and still fail its real-world assessment because a meaningful share of visitors are on older phones or slower mobile networks.

The pattern I see most often

The most common mistake I run into is treating Core Web Vitals as a one-time fix instead of a byproduct of how a site is built. A client adds a new carousel plugin, a chat widget, and a font loaded from a third-party CDN, each for a good reason, and over time the LCP score quietly drifts from a comfortable range into "needs improvement" with no single moment where anything visibly broke. Nobody broke anything on purpose. The score degrades as scripts accumulate, because every third-party script competes for the same rendering thread the browser needs to paint your content.

This is also why Core Web Vitals problems rarely get solved by a single plugin or a "speed optimization" service promising a quick fix. The scripts causing the delay are usually doing something the business asked for: tracking pixels, chat tools, review widgets. Fixing the metric means deciding which of those tools earns its place on the page, not adding another script on top of the ones already slowing it down.

What a good score actually requires

Google's thresholds are specific: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, measured at the 75th percentile of your visits. That percentile detail matters. Three out of four of your visits need to pass the threshold, not just your best-case load. A site that looks fast when you test it yourself on office wifi can still fail this bar if a meaningful share of visitors are on mobile data.

For LCP, the fix usually lives in what loads first: image compression and format (WebP or AVIF instead of an uncompressed PNG), and making sure the hero image isn't waiting behind a queue of render-blocking scripts. For INP, the fix is almost always JavaScript execution time. Long tasks on the main thread delay every interaction that happens during them, so trimming unnecessary scripts helps more than any single line of optimized code. For CLS, the fix is reserving space: explicit width and height attributes on images, and font-display settings that keep your layout stable while a custom font loads.

How to actually measure this without guessing

Search Console's Core Web Vitals report is a start, but it groups URLs into patterns and can lag your actual traffic by weeks. If you want a number you can act on today, pull the CrUX (Chrome User Experience Report) data directly through the CrUX API or the PageSpeed Insights tool, which reads from the same underlying dataset Google uses for ranking. That's the field data: real Chrome users, real devices, real networks, aggregated over the trailing 28 days.

Lab tools like Lighthouse and WebPageTest measure something different: a single simulated page load under a fixed set of conditions you choose. They're useful for debugging because they show you a waterfall of exactly what loaded when and let you isolate one script at a time, but the score they produce is not the score Google uses to evaluate your site. I've had clients chase a perfect Lighthouse score for weeks while their real-user CLS stayed in the red because a client-side ad script, invisible to a lab test that blocks ads by default, was still shifting layout for actual visitors.

The practical order I use: check the Search Console report first to see which URL groups are failing and on what metric, pull field data for a specific URL through PageSpeed Insights to confirm the failing metric and get a percentile breakdown, then use Lighthouse or a browser's own performance panel to find which specific resource is causing it. Skipping straight to the lab tool means fixing a problem your real visitors might not even have.

A worked example: chasing down a slow LCP

Say Search Console flags a service page with LCP failing at the 75th percentile. Open the page in Chrome DevTools, go to the Performance panel, and record a fresh load with cache disabled and a throttled connection profile close to what a real mobile visitor would see. The panel highlights the LCP element directly and shows a timeline of everything that happened before it painted.

In a typical case, the LCP element turns out to be a hero image, and the waterfall shows three render-blocking stylesheets and a font file loading before the browser even starts requesting that image. The fix isn't compressing the image, since it might already be well optimized. It's moving the image request earlier: adding a preload hint for it in the document head, deferring the non-critical CSS, and making sure the image isn't hidden behind a JavaScript component that has to hydrate before the browser knows the image exists at all.

That last point trips up more sites than any other cause I see. A hero section built as a client-rendered component means the browser has to download, parse, and execute JavaScript before it even discovers the image URL, adding a full render cycle to what should be a simple asset request. Server-rendered or static markup puts the image URL directly in the initial HTML, where the browser's preload scanner can find it immediately. This is exactly the kind of decision that lives below what a visitor or a stakeholder ever sees, which is part of a broader pattern I cover in the technical layer buyers never see: the work that determines whether a site performs well is mostly invisible until it's broken.

If you want the fuller picture of how signals like this fit into technical SEO as a system rather than a checklist, I've laid that out in how technical SEO actually works.

A worked example: fixing a bad INP score

INP problems show up differently from LCP problems, and the fix usually isn't obvious just from looking at the page. Say Search Console flags a filter page failing INP at the 75th percentile. The visible page seems fine. Nothing lags when you click around it yourself on a fast laptop on office wifi.

Open the Performance panel again, but this time record an interaction instead of a page load: click the filter control, apply a filter, and stop the recording. The panel breaks the interaction into three phases: input delay (time before the browser starts processing the click), processing time (how long your code takes to run), and presentation delay (time to paint the result). Most INP problems live in the processing phase, not the other two.

In a typical case, clicking the filter triggers a chain of work that's easy to miss reading the code casually: an event handler fires, it calls a state update, the state update re-renders more of the page than it needs to because the component tree wasn't split finely enough, and that re-render blocks the main thread long enough for the browser to miss its next paint frame. None of this shows up in a page-load trace. It only shows up when you record the interaction itself.

The fix is rarely "remove JavaScript." It's narrowing the blast radius of what a single click has to touch: breaking a large component into smaller ones so a filter click only re-renders the filtered list instead of the entire page shell, and moving expensive work like re-sorting a large array off the main thread with a web worker, or deferring it until after the visible update has already painted.

Why CLS problems come back after you think you've fixed them

CLS has a habit of reappearing months after you've cleared it, and the reason is usually a piece of the page you don't control directly. Ads, embedded review widgets, and third-party chat tools load on their own schedule, and a new version of any of them can start injecting a banner or resizing a container without your own codebase changing at all.

The layout shifts that survive longest are the ones that only show up for a subset of visitors: a cookie consent banner that renders above the fold only in certain regions, a personalized recommendation carousel that takes an extra beat to fetch data before rendering at a different height than its placeholder, or a web font that swaps in with different metrics than the fallback font it temporarily replaced. Your own testing, from your own browser, in your own region, often never triggers any of these.

The fix that holds up is reserving space defensively rather than reactively: giving every third-party embed a fixed-height container before its content loads, matching your fallback font's line height and character width to your web font as closely as possible, and treating any new script added to the page, however small, as something that needs a CLS check before it ships rather than after a client asks why the score dropped.

When Search Console doesn't have enough data to trust

Not every page gets its own Core Web Vitals verdict. CrUX, the dataset behind the field data, only reports on a URL once it has collected enough real Chrome traffic to be statistically meaningful. A new page, a low-traffic service page, or a page on a smaller site can sit with no URL-level data at all, even months after launch.

When that happens, Search Console and PageSpeed Insights fall back to origin-level data: an aggregate across every page on your domain, weighted toward whatever gets the most traffic. That's a useful general signal, but it can hide a problem specific to one template. A site with a fast homepage and blog can show a healthy origin-level score while a slow, JavaScript-heavy service page template underneath it never accumulates enough traffic to surface its own number.

If you need certainty on a specific low-traffic page rather than the origin average, lab data is the only option left, since field data simply isn't available yet. Run it through Lighthouse with a realistic mobile throttling profile, cross-check the code path against a similar page that does have field data, and treat the lab result as a reasonable proxy until the page earns enough real traffic to report on its own. Sequencing this kind of diagnostic work into an actual improvement plan, rather than a one-off test, is the kind of thing I do as part of SEO consulting.

Core Web Vitals is one technical signal among several. If Search Console is also flagging pages as crawled but not appearing in results, that's a separate, content-and-links problem, not a speed problem, and if you've read about crawl budget and wondered whether it applies to a site your size, it almost certainly doesn't yet. More in the Technical SEO archive.

Where this fits in your priorities

Core Web Vitals is one input among many in how Google ranks a page, not the deciding factor. A page with excellent scores and weak content will not outrank a page with strong content and mediocre scores. Treat it as a floor to clear rather than a ceiling to chase: get your site out of the poor or needs-improvement range, confirm the fix with real user data in Search Console rather than a single lab test, and put your remaining effort into the content and structure decisions that actually move rankings.