Article No. 42
Core Web Vitals: What They Are and How the Three Metrics Fit Together
Abstract
Core Web Vitals are three specific, measured signals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They are not a vague stand-in for "site...
On this page
Core Web Vitals are three specific, measured signals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They are not a vague stand-in for “site speed.” Each one measures a distinct part of the page experience, loading speed, responsiveness, and visual stability, and each has its own threshold and its own set of fixes.
This post is the map, not the fix-it manual. If you already know your LCP or INP score is the problem, the dedicated guides below go much deeper into causes and fixes. This one exists to explain what the three metrics are, how they relate to each other, and how to figure out which one is actually holding your pages back.
Why Core Web Vitals matter
Google has used page experience, including the Core Web Vitals, as part of its ranking systems since it began rolling the signal out in mid-June 2021. Google’s own documentation is consistent on the scope of that signal: page experience is one of many ranking factors, and it functions more as a tie-breaker among pages of otherwise similar relevance and quality than as a dominant factor on its own. A page with mediocre Core Web Vitals scores but genuinely better content will still tend to outrank a faster page with worse content. Treat Core Web Vitals as a real but modest factor, not the deciding one.
That said, the metrics matter for reasons beyond ranking. They are Google’s attempt to quantify things users actually notice: does the main content show up quickly, does the page respond when you tap or click something, and does content jump around while you’re trying to read or interact with it. Those are usability problems independent of SEO.
The three metrics, one table
Each metric has a “good,” “needs improvement,” and “poor” threshold, and each is assessed at the 75th percentile of real-user data collected through the Chrome User Experience Report (CrUX), meaning at least 75% of a page’s visits need to meet the “good” threshold for the page to be classified as good overall. This methodology and the thresholds below come directly from web.dev’s Core Web Vitals documentation.
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading speed: when the largest visible element finishes rendering | ≤2.5s | 2.5s–4.0s | >4.0s |
| INP (Interaction to Next Paint) | Responsiveness: how long the page takes to visually respond to interactions | ≤200ms | 200ms–500ms | >500ms |
| CLS (Cumulative Layout Shift) | Visual stability: how much visible content shifts unexpectedly | ≤0.1 | 0.1–0.25 | >0.25 |
A short history: FID to INP
Until March 12, 2024, the third metric was First Input Delay (FID), not INP. FID only measured the delay before a browser could begin responding to a single, first interaction on a page. Google announced INP as FID’s eventual replacement in May 2023, and it became the official third Core Web Vital on March 12, 2024, per web.dev’s announcement. INP measures the full response latency, not just the initial delay, across every interaction on the page, which makes it a more complete picture of whether a page actually feels responsive. If you want the full mechanics of how INP is calculated and fixed, that lives in the dedicated INP guide, not here.
CLS at a glance
CLS measures how much visible content moves around without the user doing anything to trigger it, like text shifting down because an image above it just finished loading. Per web.dev’s guidance on optimizing CLS, the most common causes are:
- Images and embeds without reserved dimensions. If the browser doesn’t know an image’s size in advance, it can’t reserve space for it, so the layout jumps when the image loads.
- Web fonts that swap in late. Depending on how a font is loaded, the fallback text can render at a different size or width than the final font, shifting everything below it.
- Content injected above existing content. Ads, embeds, and dynamically loaded banners that get inserted above the fold push everything below them down.
CLS is usually the cheapest of the three metrics to fix. Reserving space with explicit width/height attributes or CSS aspect-ratio, and being deliberate about where and when dynamic content gets injected, solves most CLS problems without needing a rebuild.
How the three metrics interact
Optimizing one metric in isolation can hurt another. A few common examples:
- Applying
loading="lazy"to a hero image (the element that’s often also your LCP element) can delay LCP, because the browser deprioritizes the image instead of fetching it early. - Injecting content dynamically to reduce initial page weight (a common LCP or INP tactic) can create a CLS problem if that content isn’t given reserved space.
- Deferring JavaScript to improve LCP can push more work into the browser’s idle time, which can create INP problems if that deferred work runs during a user interaction.
None of this means the metrics are in constant conflict. It means fixes should be tested together, not assumed to be free wins for one metric with no effect on the others.
Finding out which metric is actually your problem
Before reaching for a fix, diagnose. Three tools cover most of what you need:
- PageSpeed Insights. Gives you both lab data (a simulated test run) and, when available, field data (real CrUX numbers) for the URL you enter.
- Search Console’s Core Web Vitals report. Groups your indexed URLs by metric and status (good/needs improvement/poor) using real field data across your whole site, not just one page.
- The CrUX dashboard or API. Useful if you want historical trend data or need to check a URL that doesn’t have enough traffic to show up in Search Console’s report.
Field data (real users) and lab data (simulated tests) can disagree, and when they do, field data reflects what’s actually happening for your visitors. Lab data is more useful for debugging a specific fix before you ship it.
One detail that trips people up: CrUX data, and by extension Search Console’s Core Web Vitals report, is split by device form factor, mobile and desktop are tracked and scored separately. A page can be “good” on desktop and “poor” on mobile at the same time. If you’re only checking one device view, you’re only seeing half the picture. The CrUX API and CrUX Dashboard let you segment further, including tablet, if you need that level of detail.
Where to go next
If your problem is LCP, the Largest Contentful Paint (LCP): Causes and Fixes guide breaks down the four load phases that make up the metric and how to diagnose which one is slow. If your problem is INP, the Interaction to Next Paint (INP): Causes and Fixes guide covers the calculation methodology, long tasks, and third-party script impact in full depth.
Core Web Vitals are worth taking seriously, but they’re also just three specific, well-defined measurements. Once you know which one is actually broken on your site, the fix is usually more mechanical than mysterious.