Beyond Core Web Vitals, which performance metrics do you monitor, and how do you measure them in production?

Question

Accepted Answer

Core Web Vitals, meaning LCP, INP which replaced FID, and CLS, are the baseline. They are what Google measures and what most teams report, but they describe page loading and responsiveness rather than whether the product actually feels good to use.

I monitor several things beyond them. Time to First Byte separates server and network problems from front-end problems; when LCP regresses, TTFB tells me immediately whether to look at the backend or the bundle. First Contentful Paint shows how quickly the user sees anything at all. Total Blocking Time is the lab counterpart to INP and is far easier to act on, because it points directly at long tasks. I also track long tasks themselves, meaning any main-thread block over fifty milliseconds, since they are the root cause behind most interaction problems.

Beyond browser metrics I track business-level timings that the framework does not define for me. How long until the primary action of the page is usable. How long a search returns results. Error rate and JavaScript exception rate, because a fast page that throws is not a fast page. Bundle size per route, tracked in CI so a regression is caught before it ships rather than after.

On measurement, the essential distinction is lab versus field. Lab data comes from Lighthouse or WebPageTest on controlled hardware. It is reproducible and good for catching regressions in CI, but it is one synthetic device on one network and it will not reflect your actual users. Field data, real user monitoring, comes from real sessions on real devices. I collect it with the web-vitals library, which reports the same metrics Chrome reports, and send them to an analytics endpoint alongside device, connection type, and route.

Two habits make the data usable. First, look at percentiles, not averages. The mean hides the tail, and the tail is where users churn. I report p75 as the headline, which is what Core Web Vitals uses, and watch p95 for the worst experiences. Second, segment. An aggregate number across all routes and devices is close to meaningless; a slow LCP concentrated on low-end Android on one specific route is an actionable bug.

Finally, tie the numbers to an alert and a budget. A dashboard nobody opens does not prevent regressions. Performance budgets in CI plus alerting on field p75 is what actually keeps a codebase fast over time.