Performance Measurement and Tooling
Two kinds of performance data exist, and confusing them wastes hours. Lab data comes from a controlled test you run on demand. Field data comes from real visitors. You debug in the lab and you are graded in the field, so you need both and you need to know which is which.
Lab versus field
Lab data comes from a controlled synthetic test: one machine, one network, run whenever you want. It is repeatable and great for debugging because you can change one thing and re-run. Field data, also called Real User Monitoring, comes from actual visitors on their own devices and connections, which span slow phones, weak networks, and cold caches your fast laptop never sees.
Google grades on the field, at the 75th percentile of real loads. So a page passes a metric when at least three in four real visits meet the good threshold; your fastest loads do not rescue the slow quarter. The working rule follows from the split: fix in the lab, where you can iterate, then confirm in the field, which is what actually counts. The thresholds you grade against →
Field tools
The public field source is CrUX, the Chrome UX Report: real-user data from opted-in Chrome users, reported at the 75th percentile over a rolling 28-day window and split by mobile and desktop. It is Chrome-only and it is what sits behind the field numbers in other tools. You reach it three main ways.
- PageSpeed Insights: enter a URL and read its CrUX field values alongside a lab run.
- Search Console Core Web Vitals report: URL groups rated Poor, Needs improvement, or Good from that same CrUX field data. Search Console CWV report →
- The web-vitals JavaScript library: instrument your own pages to beacon each metric from real visits, and use its attribution build to learn which element or phase caused a bad reading.
Field data lags because it is a 28-day rolling average, so patience is part of the loop. This same pattern, sampling real behavior over time rather than a single test, is how you measure AI visibility too. Measuring AI visibility parallels field CWV →
Lab tools
Lab tools tell you the cause a field metric only reports. Lighthouse measures LCP and CLS in a controlled run and names the offending elements, and it gives you Total Blocking Time as the lab proxy for INP, since you cannot generate real interactions in a synthetic test.
The DevTools Performance panel goes deeper when you need it. Record a load or an interaction and read the LCP marker to see when the largest paint landed, the Interactions track to break an INP interaction into input delay, processing, and presentation, and the Layout Shifts track to catch exactly what moved. Use the field tools to learn which metric fails, then use these to learn why. Attribution to debug INP →
Field tools tell you which metric fails. Lab tools tell you why. Run them in that order and you stop guessing at fixes for a problem you have not located.
Budgets and the measurement loop
Once a page is fast, the risk is quiet regression: a new script or an unsized image creeps in and the number drifts back up. A Lighthouse CI budget guards against that by failing the build when a metric crosses a limit you set, so a regression is caught before it ships instead of weeks later in the field.
That closes the loop. Start in the field to see which metric fails at the 75th percentile. Reproduce it in the lab to find the cause. Fix it. Confirm the fix in the lab. Then wait for the 28-day field data to update and confirm the win where it counts. The loop is slow at the end on purpose, because the grade lives in the field and the field takes 28 days to catch up.