Web Vitals are Google’s standardized metrics for loading, interactivity and visual stability, and each one has fixed thresholds that sort a measurement into Good, Needs Improvement or Poor. Mixing up the cut-offs — or the units — leads to chasing the wrong number. This reference lists every threshold and lets you paste a measured value to see exactly which bucket it lands in.
How it works
Each metric has two cut-offs. A value at or below the Good threshold is good; a value above the Poor threshold is poor; anything in between is Needs Improvement. The three Core Web Vitals are LCP (loading — Good ≤ 2500 ms), INP (interactivity — Good ≤ 200 ms) and CLS (visual stability — Good ≤ 0.1, a unitless score). The diagnostic metrics FCP (Good ≤ 1800 ms) and TTFB (Good ≤ 800 ms) help explain a slow LCP, while FID is the deprecated predecessor of INP.
Crucially, Google grades a real page at the 75th percentile of field data collected from actual users, split between mobile and desktop. A page passes Core Web Vitals only when LCP, INP and CLS are all Good at that percentile, so the occasional slow session will not fail a page that is fast for most visitors.
Each metric explained
LCP — Largest Contentful Paint
LCP measures when the largest visible image or text block in the viewport finishes rendering. Good: ≤ 2,500 ms. Poor: above 4,000 ms.
LCP is most often limited by one of four causes: slow server response time (fix with TTFB), render-blocking resources like synchronous <script> tags in <head>, image load time for the largest element, and client-side rendering delays where the LCP element is injected by JavaScript after initial paint. Identifying which cause dominates for your page determines the fix.
INP — Interaction to Next Paint
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. It measures the latency from any user interaction — click, tap, key press — through to the next paint. Good: ≤ 200 ms. Poor: above 500 ms.
INP is harder to optimize than FID because it captures the worst interaction over the entire page session, not just the first. Long JavaScript tasks that block the main thread during any user interaction push INP up. The primary fixes are breaking up long tasks using scheduler.yield(), moving computation off the main thread, and avoiding synchronous layout and forced reflows during event handlers.
CLS — Cumulative Layout Shift
CLS measures unexpected visual instability — elements moving or appearing after initial load. Good: ≤ 0.1. Poor: above 0.25. CLS is a unitless score, not milliseconds; it is the product of impact fraction (how much of the viewport shifted) and distance fraction (how far it moved).
Common CLS sources: images without explicit width and height attributes, late-loading ads and embeds, web fonts that cause text reflow (mitigated by font-display: optional or preloading), and dynamically injected content above existing content.
FCP — First Contentful Paint (diagnostic)
FCP marks when any text or image first becomes visible. Good: ≤ 1,800 ms. Poor: above 3,000 ms. FCP is a diagnostic metric — it is not a Core Web Vital and does not directly affect ranking — but a slow FCP usually indicates a slow TTFB or significant render-blocking resources, both of which also harm LCP.
TTFB — Time to First Byte (diagnostic)
TTFB measures the time from the request being sent to the first byte of the response arriving. Good: ≤ 800 ms. Poor: above 1,800 ms. TTFB is primarily a server and network metric. Slow TTFB can come from slow origin server response times, long redirect chains, lack of CDN caching, or geographic distance between the user and the server.
The 75th percentile rule in practice
Measuring the 75th percentile of field data means Google looks at the slowest quartile of your real users. If 25% of your visitors have a poor experience, that typically pushes the 75th percentile into the Poor or Needs Improvement range even if the median is fast. This is why performance optimizations that help the slowest users — better lazy loading, reduced JavaScript on low-end devices, CDN distribution — move the 75th percentile more than optimizations that make fast sessions faster.
Lab vs field measurement
Lighthouse and PageSpeed Insights provide lab measurements: simulated network and CPU conditions, no real user interactions. For INP especially, lab measurement is inadequate — there is no way to simulate the full range of user interactions. Field measurement through the web-vitals library or PerformanceObserver captures real CLS and INP events as users actually interact with your page. The Chrome User Experience Report (CrUX) aggregates field data across real Chrome users for publicly accessible URLs.
Tips and notes
Measure in the field, not just the lab: lab tools like Lighthouse cannot simulate
real interaction patterns, so lab INP and CLS often differ from what users
experience. Use the PerformanceObserver API or the web-vitals library to
capture field values, and remember that CLS is a unitless score while every other
metric here is measured in milliseconds.