Core Web Vitals as requirements.

Picture a rider on the Cobbleway shop with a squealing rear brake and a phone that is two years old. They open a product page for resin brake pads. Three questions run through their head without words. Has the thing I came for shown up yet? When I tapped the size, did the page react? Is the button still where I am about to press it? Every complaint about a slow site is one of those three in disguise.

Core Web Vitals give each question a metric measured inside the browser. Largest Contentful Paint (LCP) is the moment the biggest piece of content in the viewport finished drawing, a stand-in for "the page has arrived". Interaction to Next Paint (INP) is how long the page took to show a visible response after a click, tap or key press, taking close to the worst one in the visit. Cumulative Layout Shift (CLS) scores how much visible content moved without the user asking it to.

Each metric comes with two thresholds that split values into good, needs improvement and poor. The thresholds are not judged on one lucky test run. A page meets the bar when at least three out of four real page loads are good, measured separately for phones and for desktops. That last part is what turns a metric into a requirement: a number, a percentile, a device class and a data source, all of which can be checked by someone other than the person who wrote the code.

While the page loads, the browser keeps a running answer to "what is the biggest piece of content on screen right now?". Each time something larger finishes painting it records a new candidate, and the last candidate before the user interacts is the LCP. Only some elements can be candidates: an img, an image inside an svg, a video (its poster or first presented frame, whichever comes first), an element whose background image comes from url(), and block-level elements that hold text.

Size means the part the user can see: whatever is off screen or clipped does not count, and neither do margins, padding or borders. Chromium also skips elements that are invisible (opacity 0), elements that cover the whole viewport (treated as background) and low-entropy placeholder images, so a blurry stand-in cannot claim the prize. Once the user taps, scrolls or presses a key, no new candidates are recorded; whatever was largest by then is the page's LCP.

INP watches every click, tap and key press for the whole time the page is open, not only during loading. Hovering, scrolling and zooming are not counted. For each interaction the browser measures from the moment of input until the next frame is presented on screen, because that frame is the first chance the user has to see that something happened. The page's INP is the slowest of those interactions, with one allowance: for every 50 interactions, the single highest is ignored, so one hiccup in a long session does not define it. A visit with no counted interactions has no INP at all.

Each interaction's latency is three phases in a row. Input delay is how long the event waited before its handlers could start, usually because the main thread was busy with something else. Processing duration is the time spent in the event handlers themselves. Presentation delay is what comes after the handlers: recalculating styles, layout, paint and getting the frame to the screen. The three always add up to the interaction's latency, which is why INP is reported with them: each phase has a different owner and a different fix.

A layout shift happens when an element that was already visible starts a frame in a different position than it had in the frame before. The browser scores each shift by multiplying two fractions of the viewport: how much of the screen the moving elements touched across both frames (the impact fraction) and how far the farthest of them travelled, relative to the viewport's larger side (the distance fraction). On a portrait phone, cards that cover half the viewport and drop by a tenth of its height touch 60% of it across the two frames (their old and new positions together), so the shift scores 0.6 × 0.1 = 0.06.

Shifts are then grouped into session windows: a window keeps growing while each new shift comes less than 1 second after the previous one, and it closes after 5 seconds at most. CLS is the total of the worst window over the page's whole life, not the sum of everything, so a long-lived page is not punished just for being open. Shifts the user caused are left out: any shift within 500 ms of a tap, click or key press is flagged as having recent input and does not count, and animations done with CSS transform do not move layout at all. The causes and cures of each kind of shift are the subject of the Layout stability topic.

Every page load produces one value per vital, and a busy page produces thousands a day. To turn that pile into a pass or a fail, the program takes the 75th percentile: sort the values and read off the one that three quarters of loads beat. If p75 LCP is 2.4 s, at least 75% of loads painted their main content within 2.4 s. The median would let half of all visits be slow; p95 or p99 would be dominated by a handful of terrible connections the site cannot fix. p75 sits between those, demanding that most visits are good while staying robust to outliers. The general maths of percentiles, and why you never average them, is in the backend topic on latency percentiles.

Phones and desktops are judged separately, against the same thresholds. The thresholds are the same because a person on a phone is no more patient than one at a desk; the assessment is split because mixing them hides the slow group. When most of a site's traffic is desktop, a blended p75 can pass while most phone loads are slow. In a requirement this means two lines, or one line that says "each".

Field data comes from real visits: Chrome's public CrUX dataset (a 28-day rolling window, split by phone, desktop and tablet) or the site's own real-user monitoring. Lab data comes from a scripted load of one URL on one simulated device and network, as Lighthouse does. The thresholds were set for field data at p75, and that is what a Core Web Vitals requirement is judged on. A standard Lighthouse page-load run cannot even produce INP, because nobody taps during it; it reports Total Blocking Time as a stand-in. Lab runs are still essential, but for a different job: they are repeatable, so they catch a regression in a pull request long before 28 days of field data notice it. How the two are wired into a release process is covered in Lab data, field data and releases.

Illustrative numbers, but a common shape. About seven in ten Cobbleway visits come from phones, and every failure is on a phone; the desktop columns pass everything. A team that tests on office laptops would see a healthy site, and one blended number per page would make the phone failures look smaller and would not say which device class to fix. Splitting by template matters as much as splitting by device: each template has its own LCP element, its own interactions and its own late content, so the fix for the product page's photo does nothing for the category page's filter chips.