Core Web Vitals

INP measures discrete interactions — clicks, taps and key presses — timing each from the user's input to the next frame painted after the page responds. Scrolling and hovering are excluded, and one value per page visit is reported.

LCP records when the largest content element visible in the viewport finished rendering, timed from the start of navigation. Eligible candidates are images, SVG <image> elements, video poster frames, elements with a CSS background-image, and block-level elements containing text.

First Contentful Paint marks the moment the browser first renders any piece of DOM content — text, an image, a non-white canvas or an SVG. It proves the page has stopped being blank, but says nothing about whether the main content or anything usable has arrived.

Each shift scores impact fraction times distance fraction: the share of the viewport the moving content covered before and after, times how far it moved relative to the viewport's larger side. The page reports the largest sum inside one session window.

Input delay is the wait before any handler runs, usually because the main thread is busy. Processing time is the event handlers themselves. Presentation delay is the styling, layout and paint work needed before the next frame shows the result.

FID timed only the queueing delay before the first interaction's handler started. INP measures every qualifying interaction all the way to the next paint, so slow handlers, heavy rendering, and interactions after the first one — all invisible to FID — now count.

Split LCP into four consecutive phases: time to first byte, resource load delay (before the LCP resource starts downloading), resource load duration, and element render delay. Each phase points at a different cause, and a text LCP has both resource phases at zero.

TTFB measures the time from the start of a navigation until the first byte of the main document's response arrives. It folds in redirects, DNS, connection setup, TLS and server processing, so every paint metric can only begin after it.

A URL passes only when every Core Web Vital — LCP, INP and CLS — sits in the good band at the 75th percentile of real visits, evaluated separately for mobile and desktop over a trailing 28-day window of field data.

Each Core Web Vital has two fixed boundaries that split its values into good, needs improvement and poor. Every real visit produces one value that lands in one band, and the bars show the share of visits in each band.

The browser reports a new LCP candidate each time something larger paints and stops looking once the user first interacts — a tap, click, scroll or key press — or once the page is backgrounded. An impatient user who scrolls early freezes the value at whatever had painted by then.

Total Blocking Time sums the blocking portion of every long task during load — the milliseconds each task runs beyond 50ms. It estimates how unresponsive the page would have been to input, which lab tools use as a proxy because no synthetic run has real user interactions to measure.

Field Core Web Vitals are aggregated over a rolling 28-day window, so a week after a deploy roughly three quarters of the samples still come from the old code. The reported value drifts as the window rolls; your own real-user data shows the change the same day.

Injecting content above existing content moves nearly everything on screen, so the impact fraction approaches 1, and two injections seconds apart land in the same session window and add. Fix it by rendering the bars in the initial HTML, or taking them out of document flow.

CLS keeps accruing for the whole document lifetime and is not reset by a client-side route change, so any view transition can define the score. Attribute shifts by logging each layout-shift entry with its value, timestamp, source nodes and the current route.

A fast handler only rules out the processing phase. The remaining time is either input delay — the main thread was busy when the click arrived — or presentation delay, the style, layout and paint work the handler's DOM changes triggered. Capture the phase breakdown from real users to tell which.

INP reports the slowest interaction of the visit, not an average — but on interaction-heavy pages it discards roughly one outlier per fifty interactions, so on a long session a single freak stall can be the discarded one and never surface.

Dominant load delay means the browser found out about the LCP resource too late — it was not in the initial HTML, or was deprioritised. Dominant render delay means the bytes arrived but painting was blocked, by render-blocking resources, a busy main thread, or content that only exists after client-side rendering.

On page A almost all of the 4 seconds is spent before anything renders, so the problem is the server or the network and no front-end change will help. On page B the browser painted in half a second and then waited 3.5 seconds, so the largest element itself is the problem.

A single test measures one device, one network, one location and one page state; the field assessment reads the 75th percentile across every real visit, including slow phones and bad networks. Some vitals also cannot be produced by a load-only test at all.

Field datasets publish a URL-level record only when that URL has enough qualifying visits in the window; low-traffic pages get none and fall back to the origin aggregate, which is traffic-weighted across every page on the site and therefore describes your busiest templates, not this page.

Speed Index scores how quickly the visible viewport fills in during load, computed from frame-by-frame visual progress rather than from a single event. Unlike milestone metrics it rewards steady progressive rendering and penalizes a page that stays blank and then appears all at once.