Field data and lab measurement.
Field data shows the performance real users experience; lab measurement shows performance simulated in a controlled environment.
The most expensive misunderstanding in performance debates is skipping this distinction. A team scores ninety-five in an audit tool, declares “we are fast,” and real users keep experiencing the same page as slow. Both are true, because the two measure different things.
Lab measurement assumes a fixed device, a fixed network and a single load. Field data is the distribution of real devices, real networks and real usage patterns. The second always comes out worse, and that is normal.
Which question with which tool
- “What of ours is slow?” — lab. Repeatable, detailed, shows cause and effect.
- “Did the change work?” — lab. Before and after can be compared under identical conditions.
- “What are our users experiencing?” — field. The only honest answer lives here.
- “How does Google see us?” — field. This is the data used in ranking.
- “How is our INP?” — field. It cannot be measured reliably in the lab.
The last row matters especially: the interaction responsiveness metric by definition looks at real user interactions, and an audit tool does not interact with the page. Tools produce an estimate, but that estimate does not represent real use.
The limits of field data
Field data is not flawless either, and its limits must be known. First, it lags: the reported values come from a twenty-eight-day window, so the effect of a fix made today shows weeks later.
Second, it needs a threshold: for sites without enough traffic no data is collected and the report stays empty. A new or low-traffic site may have no field data at all.
Third, it is aggregate: it can be reported for groups of similar pages, not per page. Finding which page is the problem requires additional measurement.
On this site the field data is pulled into a cache file and shown on screen — but when there is no data, the field is NOT RENDERED at all. The verification suite measures both directions: with a value present, the number in the strip must match the cache exactly; with no value, the word “measured” must never appear.
When there is no data, the field is left empty; a fabricated proof is not written.
Setting up your own measurement
There is a third path, and it fills the space between the two worlds: collecting real user data with a small measurement snippet added to your own page. The browser reports all three metrics to the page, and those values can be sent to your own system.
The advantage is detail: you can see which metric is bad, on which page, in which device class and on which element. An aggregate report gives you a number; your own measurement says where that number comes from. And there is no lag — the data arrives instantly.
On the privacy side it can be built clean: the measurement needs no cookies and collects no personal data; only duration values and the interacted element’s selector are recorded. On this site the privacy text says no cookies are used and the suite measures it — an added measurement cannot break that claim; if it does, the test turns red.
The score itself is a trap
The single-number score audit tools print is handy for communication and dangerous for decisions. The score is a weighted average of several metrics, and the weights change over time — the same page can score differently with no code change at all.
More importantly, once the score becomes a target, the team starts raising the score, not the performance. The two usually move together, but where they diverge the score wins — and at that point the measurement has gotten in the way of the improvement.
The healthy use: look not at the score but at the sub-metrics, find which one is broken, and fix that. Let the score rise as a consequence; do not set it as a goal.
And the final referee is always the field data. A page with a lab score of ninety-five can be bad for real users; one scoring seventy can be good. When both are measured, which is true is beyond debate.
Reading the two together
The most valuable information appears where the two DIVERGE, and that divergence can serve as a diagnostic tool. Lab good, field bad: the cause is usually the device and network distribution — your users run weaker hardware than you test on. The treatment is cutting JavaScript and freeing the main thread.
The reverse is rarer but informative: lab bad, field good likely means the measurement settings are harsher than the real user distribution. Not a bad state — it only shows the lab settings are too pessimistic.
Both bad is the clearest state, and the diagnosis is made from the lab measurement. Both good is the only real success indicator — and at that point the measurement’s purpose is no longer improvement but regression watch.
The practical rhythm: field data is read monthly for overall health; the lab measurement runs on every deployment and catches regressions. The two run at different tempos because they answer different questions.
One last practical note: when comparing the two measurements, make sure you compare the same page. Field data can be reported in page groups, and the group may include pages other than the one you tested. Comparing the home page’s lab score with the whole site’s field data is comparing two different things, and it leads to wrong conclusions.
A practical checklist
Turning this page into an audit step, here is what to check across the two measurement layers. The list is kept short because long lists do not get walked; six items fit in one sitting.
- Is there field data — if not, you are under the traffic threshold.
- Which metric is broken — look at the three separately, not at the score.
- Do lab and field diverge — the direction of the divergence gives the diagnosis.
- Are mobile and desktop read separately?
- Is your own measurement in place — the detail lives only there.
- Is the measurement rhythm set — field monthly, lab on every deployment.
The fifth item is the most skipped: an aggregate report gives you a number; your own measurement says which page and which element that number comes from.