Core Web Vitals

Core Web Vitals are the subset of Google's web performance metrics that describe what a page feels like to use: how quickly the main content appears, how promptly it responds to input, and how much it moves about while loading. They are published with explicit numeric thresholds, which is what separates them from most performance advice.

The three metrics and their thresholds

From Google's Web Vitals documentation:

Two details in that table are more important than the numbers themselves.

The percentile. Google recommends measuring at the 75th percentile of page loads, segmented across mobile and desktop devices, so the target holds for most users rather than for an average that conceals a slow tail. A median that passes while the 75th percentile fails is a page that is failing for a quarter of its visitors.

The metric that changed. Interaction to Next Paint replaced First Input Delay as the responsiveness metric. Guidance still naming FID is stale, and that is a convenient way to date an article about page performance without reading it closely.

These are also field metrics, gathered from real visits. A synthetic laboratory run is a diagnostic tool, not the measurement, and the two routinely disagree because real devices and real networks are worse than a test harness.

What they do and do not affect

They are a real input to Google's ranking systems, and they are a modest one. A page with nothing worth reading does not rank because it loads quickly, and no threshold here compensates for that.

For AI search the honest answer is narrower still. There is no published mechanism connecting Core Web Vitals to being cited in a generated answer, and Google states that there are no additional requirements to appear in its AI experiences and no other special optimizations necessary. What does connect, mechanically rather than as a ranking factor, is fetchability: an assistant answering from retrieval performs a live HTTP fetch under a timeout. A page that is slow to return, or that shows nothing until client-side JavaScript has run, can drop out of a candidate pool before any judgement about its content occurs. That failure is upstream of quality, and it is the same class of problem as being blocked in robots.txt — see crawling and indexing and AI search.

How to act on it

1. Measure in the field, at the 75th percentile, split by device. Anything else is a proxy.
2. Treat the thresholds as thresholds. Once a page is comfortably inside all three, further optimisation buys nothing measurable and the effort belongs elsewhere.
3. Fix LCP by shipping less before it. Render-blocking resources, unsized hero images and late-loading fonts account for most failures.
4. Fix CLS by reserving space for images, embeds and anything injected after first paint. Layout shift is almost always missing dimensions.
5. Serve the substance without client-side rendering where you can. That is the change that helps both a slow phone and a retrieval fetch under a timeout, and it is the only item on this list with any bearing on AI visibility.

Frequently asked questions

What are the three metrics and their thresholds?

LCP within 2.5 seconds, INP of 200 milliseconds or less, CLS of 0.1 or less.

Is First Input Delay still included?

No. Interaction to Next Paint is the current responsiveness metric.

Which percentile is judged?

The 75th percentile of page loads, split across mobile and desktop.

Do they affect AI citation?

Not through any published mechanism. The real link is fetchability under a timeout.