Core Web Vitals are three metrics for loading, responsiveness and visual stability. This reference lists the current thresholds, explains field versus lab data, and sets out what Google says about their role in ranking.
Core Web Vitals measure real-world user experience for loading, interactivity and visual stability. Largest Contentful Paint (LCP) measures loading. Interaction to Next Paint (INP) measures responsiveness. Cumulative Layout Shift (CLS) measures visual stability, meaning how much content jumps around.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 s or less | Above 2.5 s up to 4 s | Above 4 s |
| INP | 200 ms or less | Above 200 ms up to 500 ms | Above 500 ms |
| CLS | 0.1 or less | Above 0.1 up to 0.25 | Above 0.25 |
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. The web.dev announcement is stamped 12 March 2024, though it does not spell the launch date out in the text. It says INP became a stable Core Web Vital, replacing FID.
The same announcement says Chrome tools would no longer guarantee FID availability, and that developers had until 9 September 2024 to move to INP in the CrUX and PageSpeed Insights APIs.
web.dev says PageSpeed Insights now uses INP instead of FID in its assessment. If you have reports or dashboards built on FID, update them to use INP.
Google's guidance is to measure at the 75th percentile of page loads, segmented across mobile and desktop. A page passes when it meets all three targets at that percentile.
Field data comes from real users. The Chrome User Experience Report (CrUX) is the main source. Lab data comes from a controlled test, such as Lighthouse or Chrome DevTools. web.dev says lab measurement cannot replace field measurement, because real users vary in devices, networks and interactions.
Lab tools have gaps. Lighthouse supports LCP and CLS but not INP, because it has no user input. It reports Total Blocking Time (TBT) as a proxy for INP instead.
Google's page experience documentation says its core ranking systems look at a variety of signals that align with overall page experience, and that there is no single signal. It states that Core Web Vitals are used by its ranking systems.
It also says good scores do not guarantee top rankings, because there is more to great page experience than Core Web Vitals scores alone. It says search still shows the most relevant content even when page experience is poor, and that experience matters most when many helpful pages compete for the same query. Google advises that chasing a perfect score purely for SEO may not be the best use of your time.
Google does not publish a specific ranking weight for these metrics.
Start with field data. Check the Search Console report for groups marked Need improvement or Poor, then use PageSpeed Insights on a sample URL to see the field values. Use lab tools to find and reproduce causes. Aim for the Good range on all three metrics, not a perfect score.
Re-check after each release. The Search Console report covers the last 28 days, and its fix validation also uses a 28 day monitoring window. Plan for the report to lag behind your changes. Treat the metric values for a sample URL in PageSpeed Insights as a quicker, though narrower, check.
Sources were last checked on October 13, 2026. Documentation changes, so confirm any detail that matters to a decision against the source itself.
Indexive Research. (2026, September 2). What Core Web Vitals measure, and their thresholds. Indexive AI. https://indexive.ai/research/core-web-vitals-explained
Straight answers about how we work. Still have a question? The free audit is the fastest way to get one answered for your site.
Good is LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of page loads.
A free execution audit: your prioritized backlog, effort estimates, and what we'd ship first. Read-only access, no contract.