Core Web Vitals are three metrics Google publishes to measure how a page feels to use. They quantify how fast the main content loads, how quickly the page responds when someone interacts with it, and how much the layout jumps around while it renders. Each metric has a defined threshold that separates a good experience from a poor one, and Google folds the combined result into how it ranks pages. This guide covers what the three metrics are, where the numbers come from, and how much weight they actually carry in ranking. It does not walk through the optimization work for each metric individually, because each one is a topic in its own right.
The three metrics and their thresholds #
Each Core Web Vital tracks a different moment in the loading experience. Knowing which moment a metric covers is what makes a failing score readable: a page does not just score badly, it scores badly in a specific way that maps to a specific metric.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the largest visible element finishes rendering | Under 2.5 seconds | Over 4.0 seconds |
| INP (Interaction to Next Paint) | Time from a user interaction to the next visual response | Under 200 milliseconds | Over 500 milliseconds |
| CLS (Cumulative Layout Shift) | Total unexpected layout movement during load (unitless score) | Under 0.1 | Over 0.25 |
These thresholds come from web.dev and Google’s Search Central documentation and are current as of 2026.
LCP measures loading speed. The moment a user perceives the page as loaded usually lines up with the moment the largest visible element finishes rendering, which is often a hero image but can also be a large block of headline text or a video poster. What moves LCP, and how to prioritize the hero resource, is its own subject; the Largest Contentful Paint guide handles that depth.
INP measures responsiveness. It records the latency of interactions across the whole page lifetime and reports a single value representing the worst of them, so a page that responds instantly to the first tap but stutters on the third still scores poorly. INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024. FID is no longer part of the program; where FID measured only the first interaction, INP captures the full visit, which is why a page can pass an old FID mindset and still fail INP today. The diagnosis and fixes for INP are covered separately.
CLS measures visual stability. As images load, ads render, and fonts swap, each can shift content that was already visible, and CLS adds up that movement into a unitless score. A score of 0 means nothing shifted; a score of 1 means the entire viewport shifted once. Most real pages land between 0 and 0.3. The specific causes and remedies for layout shift are their own topic.
Together the three metrics cover most of what makes a page feel fast or slow, responsive or sluggish, stable or chaotic. A page that clears all three thresholds feels solid. A page that fails one feels broken in the exact way the failing metric names.
Where the measurements come from #
Google draws Core Web Vitals data from two distinct sources, and the difference between them decides what actually matters for ranking.
Field data comes from the Chrome User Experience Report (CrUX), which collects anonymized measurements from real Chrome users who have opted into usage reporting. It reflects actual visitors loading actual pages on the devices and networks they really use. CrUX is the data that feeds Google’s ranking signal, so it is the data that matters for SEO.
Lab data comes from synthetic tools such as Lighthouse, PageSpeed Insights, and WebPageTest. These run automated tests under controlled, simulated conditions. Lab data is useful for diagnosis because it points to what is slowing a page down, but it does not directly affect ranking.
The two sources disagree often. A page can score well in a lab test run on a fast simulated connection and score poorly in CrUX data gathered from real users on slower mobile networks. That gap exists partly because the ranking assessment uses the 75th percentile of real visits, meaning a page has to perform well for three-quarters of its visitors, including the slowest quarter, to earn a good rating. A developer testing on a fast machine sees a number closer to the median, which flatters the page. When lab and field disagree, the field data is the source of truth.
How to check your own scores #
The Core Web Vitals report in Google Search Console shows the CrUX field data for a site, grouped by URL pattern and split by mobile and desktop. It labels each group Good, Needs improvement, or Poor based on LCP, INP, and CLS at the 75th percentile. Because ranking runs on mobile-first indexing, the mobile column is the one that drives the signal; strong desktop numbers do not compensate for weak mobile ones.
Two practical notes when reading the report. First, sites without enough traffic to produce reliable field data will see no CrUX numbers at all; the page is still evaluated, but the field-derived input does not apply until enough real-user data accumulates. Second, PageSpeed Insights shows both the CrUX field data and a Lighthouse lab run for a single URL, which makes it the quickest way to see the ranking-relevant number and a diagnostic breakdown side by side. Trust the field section for where you stand and the lab section for what to fix.
Why they matter for ranking #
Core Web Vitals are part of Google’s ranking algorithm, but the weight is moderate rather than dominant. A few observations keep the impact in proportion.
Content quality outranks performance. A high-quality page with weak Core Web Vitals still beats a thin page with perfect scores. The performance signal works as a tiebreaker between pages of similar relevance and authority, not as a substitute for either.
Thresholds matter more than exact numbers. Moving an LCP from 2.6 seconds to 2.4 seconds crosses the line from Needs improvement to Good and changes the signal. Shaving time within the same rating band tends not to move ranking at all, even though the measured value improved. The rating category is the unit that counts.
Core Web Vitals sit inside a broader page experience signal. That signal also weighs HTTPS, mobile-friendliness, and the absence of intrusive interstitials. A site can undermine page experience for reasons that have nothing to do with performance, such as a certificate error or a pop-up that blocks reading, so passing the three metrics is necessary but not the whole picture.
The effect compounds slowly. Fixing performance does not produce an overnight ranking jump. The signal shifts gradually as CrUX data accumulates and the algorithm reprocesses it, which is why sites that repair real problems tend to see movement over weeks rather than days.
Common questions #
Is First Input Delay still a Core Web Vital?
No. INP replaced FID on March 12, 2024, and FID is no longer part of Core Web Vitals. Any tooling or advice still centered on FID is out of date.
Do I need to hit all three thresholds to pass?
For a URL group to be rated Good in Search Console, LCP, INP, and CLS all have to meet their good thresholds at the 75th percentile. Failing any one drops the group out of the Good category.
My PageSpeed Insights score is high but Search Console says Poor. Which is right?
Search Console reports CrUX field data from real users, and that is what Google ranks on. PageSpeed Insights showing a strong lab score means the page can be fast under ideal conditions, not that real visitors are experiencing it that way. Trust the field data.
Why does my small site show no Core Web Vitals data?
CrUX needs enough real visits to produce reliable field measurements. Low-traffic pages fall below that threshold and show no data. The page is still evaluated, but the field-based input does not apply until it gathers enough traffic.
Core Web Vitals break one question, does this page work for the visitor, into three measurable pieces: does it load in time, does it respond when tapped, does it hold still while being read. The metrics are specific and the underlying question is general, which is the trap and the point at once. Teams that chase the numbers alone sometimes clear the thresholds without making the page feel better, while teams that fix the underlying experience tend to see the numbers follow. Start by pulling the mobile field data from Search Console to learn which of the three, if any, is actually failing, then dig into that metric on its own terms.