Performance measurements collected under controlled or simulated conditions for diagnosis and testing.
Lab data is collected in a controlled or simulated test. The test can specify a device profile, connection conditions and a sequence of actions, making it useful for reproducing a problem and comparing changes. It describes that test run, however, not every visit made by real customers.
A controlled test is especially valuable before a change reaches users or when a problem needs detailed investigation. Developers can examine a loading trace, find a delayed resource or repeat a troublesome interaction. The result depends on what the test actually does: a run that only loads the homepage will not exercise a multi-step booking form.
Lab and field results can legitimately differ. A simulated device, empty cache and short visit are not the same as the range of actual devices and longer sessions represented in real-user data. Neither result should be discarded simply because it disagrees with the other. Use the difference to ask which conditions or behaviors the test is missing.
Takeaway: Use lab tests to reproduce and diagnose, then check real-user evidence where available. A perfect score from one controlled run is not a guarantee that customers encounter no problems.
Example
A tutoring service changes its appointment picker. Before release, the developer tests opening the calendar, switching weeks and submitting an invalid selection under the same conditions before and after the change. That focused sequence provides more useful evidence than testing only whether the page initially loads.
What to check
Document the tested URL, tool, device profile, network settings and interaction steps. Repeat comparable runs when evaluating a change. Preserve the working user journey: removing a necessary feature merely to raise a score is not the same as making the feature responsive.
For more detail, see Web.dev lab and field data differences.