Measuring Speed With Field Data, Not Hope

Field data is the record of real visits: the Core Web Vitals your actual visitors experienced, collected over a trailing 28-day window and reported, where traffic allows, in PageSpeed Insights and the Chrome UX Report. It is the only speed evidence that describes your customers' phones, networks and locations, so it is the evidence verdicts should rest on. Lab data, from the same tools run on demand, is a simulation under fixed throttling: perfect for checking a fix today, useless as proof that visitors feel the fix. Use lab while working and field while judging, expect field verdicts to lag repairs by weeks, and where field data is absent for a page, work from lab results on a strict mobile profile plus your own testing on a mid-range phone.

Read the field section first: the three vitals from the vitals guide, each judged against its web.dev threshold, LCP 2.5 seconds or under, INP 200 milliseconds or under, CLS 0.1 or under, and the share of visits that had a good experience. Note whether the figures describe the page or the whole origin, since low-traffic pages often inherit site-level data. Then read the lab section as a work list: its opportunities are hypotheses about what to fix, ranked roughly by size, not as a second verdict. Ignore the single summary score as a target; it blends measures and changes weighting between tool versions, while the three field numbers are the contract your visitors actually signed.

The Chrome UX Report, documented by the Chrome team, publishes real-user measurements by page and by origin, which lets you do two things a single report cannot: compare your templates against each other on the same basis, and watch the trend as a line rather than a snapshot. Where a tool surfaces your data by device or connection, read mobile separately without exception. Set a monthly capture: the three vitals for the templates that earn money, saved with the date, so improvement and regression are provable across the quarters when apps, themes and content change. That small archive is the speed equivalent of the change log, and the monthly review in the pillar guide runs on it.

A fix ships today; the field window still holds three weeks of the old page, so the verdict improves gradually and can look unresponsive for a fortnight. Plan for this emotionally and managerially: judge a fix provisionally on lab results and your own device tests, schedule the field judgement a full window after the change, and write both dates in the log so nobody declares failure, or victory, at day five. Avoid stacking a second major speed change inside the same window where you can, because the field data will credit the pair jointly. Where trading forces speed of work over purity of attribution, accept the joint credit and say so; the goal is a fast store, not a courtroom.

Low-traffic pages and new stores often show no field data, which is a statement about sample size, not about speed. Fall back in order: origin-level field data if it exists, since your templates share their machinery with the pages that do have data; lab tests run consistently on the same throttled mobile profile, compared only against your own previous runs; and structured own-device testing, a mid-range phone, a cleared cache, the full purchase path, timed and noted. Record which basis each judgement used, because a lab-based pass and a field-based pass are different strengths of claim, and the log should not let them blur together by spring.

A personal device test becomes evidence when it is standardised: same phone, same network type, cache cleared for cold loads and kept for repeat loads, the same three pages, the same tasks. Note where the wait is felt, first content, main image, tap responses, shifts, rather than a single stopwatch figure, because those notes map directly onto the three vitals and onto fixes. Test also as a customer, signed out, consent banner fresh, every app and widget live: the page a returning owner sees, warmed and recognised, is not the page a new visitor from an ad meets. Most speed surprises live in that gap.

Testing at the office on fibre and calling it mobile. Testing the homepage, which is often the lightest template, and reporting the store as fast. Testing after a tool update changed the scoring and mourning a regression that happened in the ruler. Testing once, on a good day, and filing the screenshot as the truth. Each trap is avoided by the same habits: field first, money templates, same basis, saved monthly, changes logged beside the numbers. Measurement is the cheapest part of speed work and the part everything else stands on, which is why this bench gives it a full guide rather than a paragraph: a store that measures honestly will fix the right things in the right order almost by accident.