Core Web Vitals Monitoring: Catch Regressions After Release

Last verified on Nov 8, 2026.

Lab tests tell you how a page can perform. Real visitors tell you how it does. A page can pass every synthetic check and still get slower for people on mid-range phones after a release that added a script, a font or a larger hero image. Core Web Vitals regressions are also easy to miss: nothing errors and uptime checks stay green. You find out when search traffic or conversion moves.

This guide covers field monitoring: measuring vitals from real sessions, grouping them correctly and alerting when a release makes them worse.

What the evidence looks like

Google's web.dev defines three Core Web Vitals and their targets: Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) of 200 milliseconds or less and Cumulative Layout Shift (CLS) of 0.1 or less. It recommends measuring the 75th percentile of page loads, segmented across mobile and desktop. INP replaced First Input Delay as the responsiveness metric, observing all interactions on a page instead of only the first.

A beacon from the browser is the raw evidence. As an example:

{
  "ts": "2026-11-05T09:41:12Z",
  "metric": "INP",
  "value": 412,
  "rating": "needs-improvement",
  "route": "/checkout",
  "release": "2026.11.05-2",
  "device": "mobile",
  "navigation": "navigate"
}

A regression is a shift in the distribution of those values for a route and release. Interaction latency that doubles on one page shows up as the p75 of /checkout INP moving from about 180 to about 360 milliseconds on the newest release while other routes hold.

How to detect it step by step

1. Collect real-user measurements. The open-source web-vitals JavaScript library from the Chrome team provides onLCP, onINP and onCLS callbacks. The web.dev field measurement guide shows sending each value to an analytics endpoint with navigator.sendBeacon(), falling back to fetch() with keepalive. Add the route, release version, device class and connection type as dimensions.

2. Store values, not averages. The same guide warns against averages for these metrics. Keep each measurement so you can compute percentiles later.

3. Compute p75 per route, release and device.

SELECT release, device, route, metric,
       count(*) AS samples,
       percentile_cont(0.75) WITHIN GROUP (ORDER BY value) AS p75
FROM web_vitals
WHERE ts > now() - INTERVAL '1 day' AND route = '/checkout' AND metric = 'INP'
GROUP BY release, device, route, metric
HAVING count(*) >= 200
ORDER BY release

4. Compare against a baseline. Use the previous release and the same hour of the previous week. Fire when both of these hold: p75 is worse than the baseline by a set margin, such as 20%, and the sample count exceeds a floor. Add the published threshold as a second rule, so a page that crosses from good to needs-improvement always alerts.

5. Use public data as a cross-check. The Chrome UX Report is a dataset of how real Chrome users experience popular destinations, and it is the data behind the web vitals program. It is an aggregate published after the fact, so use it to confirm a long-running regression, not to catch yesterday's release. Your own beacons are the early signal.

Thresholds and pitfalls

Segment before you compare. A release that is fine on desktop and 30% worse on mobile hides in a blended percentile. Compare like devices and connection types.

Pitfalls:

• Low-traffic routes. A p75 from 40 sessions swings wildly. Set a minimum sample size and widen the window for rare pages.
• Metric timing. INP is calculated when the user leaves the page, so its value arrives after the session ends. Expect a delay before the full picture of a release is in.
• Traffic mix. A marketing campaign can bring new geographies and devices. Break out by country and device before blaming the code.
• Bots and headless browsers. Filter by user agent so automated sessions do not skew the percentile.
• Third-party scripts. Tag managers and chat widgets change between your releases. Record their versions if you can, or watch the long task and resource data around the regression.

INP is the hardest to alert on because it depends on what users do. Alert per interaction type or per component when you have that dimension.

What to do when it fires

Check the release first. Diff the bundle size, new scripts, new fonts and image changes for the affected route. If the web-vitals attribution build is in use, its attribution data points at the element, resource or event handler behind a slow value. Roll back when the regression is large and the cause is not obvious in an hour.

Add a budget to CI for the metrics you can measure in the lab and keep the field alert for the rest. Sazabi's client error detection covers a different part of the browser: JavaScript exceptions, failed fetches and hydration errors, not vitals. See also frontend breakage, dead clicks and rage clicks for signals that often move with a vitals regression, and latency spikes for the server side. To get the beacons into a pipeline, see the PostHog and OpenTelemetry pages.