What field data measures
Field data is performance recorded during real visits: real phones, real networks, real people scrolling and tapping. Nothing is simulated. Where a test decides in advance which device and connection to imitate, field data simply reports what happened, across everyone who came.
Google’s field source is the Chrome User Experience Report, gathered from Chrome users who have opted into reporting usage statistics. It appears at the top of PageSpeed Insights and behind the Core Web Vitals report in Search Console. A page is graded near the slower end of its own distribution rather than at the middle, so a comfortable typical visit does not rescue a page that is slow for a meaningful share of its audience.
Why field data matters
It is what counts. The Core Web Vitals assessment Google publishes is built from field measurements, not from a test score, so a page can pass every synthetic check and still be marked as needing improvement.
It is also more honest about your audience. A test run on a fast connection in a European data centre says nothing about someone loading the same page on mobile data in Pokhara. Field data includes those visits by definition, which is why it so often looks worse than the test — and why the gap between the two is information rather than an error.
Where field data goes wrong
The first surprise is that there may not be any. A page needs enough recorded visits before figures are reported for it, so most pages on a small site show nothing at all and are judged on the site as a whole. Improving one quiet page will not produce a visible result.
The second is delay. Figures are collected over a rolling recent window, so on the day you deploy a fix nothing changes, and the report keeps describing the old experience for weeks while the window catches up. People undo good work during that wait. The third is coverage: this is Chrome data, so visitors using Safari, iPhones and other browsers are absent, and a business with a heavily Apple audience is being judged on a slice of its traffic.
How to act on it
Use field data to decide what to fix and lab data to work out how. Start in Search Console, where pages are grouped by the problem they share, pick the group with real traffic behind it, then reproduce one of those URLs in a testing tool to find the cause. Fixing the group is what moves the report.
Split phone from desktop before concluding anything, because they usually fail for different reasons and a combined view hides both. After a change, record the deployment date and check back once the collection window has moved past it, rather than refreshing the report the next morning. Where the pages that matter keep failing on real visits, that is where sustained page speed work belongs.