Performance measurements collected from real users under their actual browsing conditions.
Field data comes from people using a website under their actual browsing conditions. It can reflect a mixture of devices, networks, locations and interaction patterns that a controlled test cannot fully reproduce. In performance work, it helps answer what visitors experienced rather than only what happened in a developer’s chosen test setup.
The dataset still has a scope. A report may cover a particular URL, a broader origin, a device category or a measurement period. It may also require enough eligible observations before showing results. Missing field data does not prove excellent performance, poor performance or zero visitors; it means the report cannot provide that particular measurement.
Field results are most useful when their context stays attached. A change in the visitor mix can affect an aggregate, and a historical reporting window can include experiences from before a recent fix. Read the report’s coverage and dates before comparing it with an immediate test or claiming that a change has already improved everyone’s experience.
Takeaway: Use real-user evidence to prioritize problems, but check what population and period it represents. Pair it with reproducible tests when you need to diagnose the underlying cause.
Example
A small shop’s product URL has no individual field result, while a tool offers a broader origin-level view. The owner keeps that distinction in the report: the broader result is useful context, not proof that the specific product page has passed every measurement.
What to check
Before sharing a performance result, record the URL or origin scope, device category, date range and metric. After a release, use immediate lab checks for regressions and allow the field dataset to reflect new visits before drawing a firm before-and-after conclusion.
For more detail, see Web.dev lab and field data differences.