What Is Core Web Vitals?

Core Web Vitals are Google's three field metrics for real-world page experience: LCP (loading), INP (responsiveness) and CLS (visual stability). Each is judged at the 75th percentile of real visits, so a page is rated "good" only when at least three quarters of visitors get a good result.

Core Web Vitals are the subset of web performance signals Google treats as most important to the user experience, and they feed into search ranking as part of the page experience signal. What makes them distinct is that they are designed to be measured in the field, from the sessions of actual visitors via real user monitoring, rather than only from a single lab test. Lab tools such as Lighthouse can estimate them, but the scores Google uses for ranking come from aggregated field data.

The three metrics and their thresholds

Each vital measures a different part of the experience and has a fixed "good" threshold:

  • LCP (Largest Contentful Paint) measures loading: the time until the largest content element renders. Good is 2.5 seconds or less; 2.5 to 4 seconds needs improvement; above 4 seconds is poor.
  • INP (Interaction to Next Paint) measures responsiveness: how quickly the page reacts to taps, clicks and key presses across the whole visit. Good is 200 ms or less; 200 to 500 ms needs improvement; above 500 ms is poor. INP replaced First Input Delay in March 2024.
  • CLS (Cumulative Layout Shift) measures visual stability: how much the layout unexpectedly moves as content loads. Good is 0.1 or less; 0.1 to 0.25 needs improvement; above 0.25 is poor.

Why the 75th percentile matters

Core Web Vitals are not averaged. Each metric is assessed at the 75th percentile of page loads, segmented by mobile and desktop. In plain terms, the 75th-percentile value is the experience that 75% of visits are at least as good as, so a page passes only when three quarters of real sessions meet the "good" bar. This deliberately weights the slower experiences that an average would hide. For example, if most visitors get a 1.8 s LCP but the slowest quarter sees 3 s or more, the page fails LCP even though the typical visit looks fine.

Because the figures come from real traffic, they pair naturally with RUM rather than scheduled checks. Note that a slow TTFB (time to first byte) feeds directly into LCP, so server and network speed are part of the loading score. Core Web Vitals describe how a page feels for people who reach it, but they cannot detect an outage on their own; that role belongs to synthetic and API monitoring. The post synthetic vs real user monitoring explains how the two layers fit together.

See also: Synthetic vs real user monitoring

Frequently asked questions

  • What are the three Core Web Vitals and their thresholds?

    LCP (loading), INP (responsiveness) and CLS (visual stability). The "good" thresholds are LCP of 2.5 seconds or less, INP of 200 ms or less, and CLS of 0.1 or less, each measured at the 75th percentile of real visits.

  • Why are Core Web Vitals measured at the 75th percentile?

    To reflect the experience of most visitors rather than just the typical one. The 75th-percentile value is the result that 75% of page loads are at least as good as, so a page only passes when three quarters of real sessions meet the threshold. This stops fast averages from hiding a slow long tail.

  • What replaced First Input Delay in Core Web Vitals?

    INP (Interaction to Next Paint) became a Core Web Vital in March 2024, replacing First Input Delay (FID). Unlike FID, which only measured the delay of the first interaction, INP assesses the responsiveness of interactions across the entire page visit, giving a fuller picture.

  • Do Core Web Vitals measure uptime?

    No. Core Web Vitals are field performance metrics collected from real visitors, so a fully down site produces no data and no signal. Detecting outages requires synthetic or API monitoring, which checks a site on a schedule whether or not anyone is visiting.