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.

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.