Field data is performance information collected from real people visiting your website, on their own devices and connections, rather than from a simulated test. It shows how fast and stable your pages actually are for the visitors you have, which is why Google uses it to judge Core Web Vitals.
How field data works
The best-known source is the Chrome User Experience Report, usually shortened to CrUX. Chrome collects timing data from users who have agreed to share usage statistics, and Google publishes it by page and by whole site. A few rules shape what you see:
- It is a rolling 28-day window. A fix you make today takes up to four weeks to show fully.
- It reports the 75th percentile. To pass, three in four visits need a good experience, so a fast result on your own broadband means little if a quarter of visitors struggle.
- It needs enough traffic. Pages with too few Chrome visits have no page-level data; Google may fall back to the figure for the whole site, or show nothing.
- It is split by device. Mobile and desktop are reported separately, and mobile is usually the weaker of the two.
You can also gather your own field data, known as real user monitoring or RUM, by adding a script that records each visit’s timings. That captures browsers CrUX does not cover, such as Safari, and lets you break results down by page type or campaign.
Why it matters
Field data is the version of your site’s speed that Google’s page experience signals look at. A test tool might give you a good score while your real visitors, on older phones or patchy mobile signal, have a slow experience. The reverse happens too: a page that looks poor in a test can pass in the field because most visitors arrive with the site already cached.
It also reflects your actual audience. A garden centre in Cornwall whose customers browse on mid-range Android phones in areas with weak coverage will see different field numbers from a city law firm whose clients mostly visit on office desktops. That makes field data the right measure for deciding whether speed work is worth paying for.
One UK detail: CrUX is collected by Chrome, so it needs nothing from your cookie banner. A RUM script you add yourself is different. If it sets cookies or stores identifiers, PECR and UK GDPR apply, and it may need to wait for consent like any analytics tool.
Common mistakes
- Treating a Lighthouse score as the verdict. That is lab data, useful for diagnosis but not what Google assesses.
- Expecting instant results after a fix. The 28-day window means the improvement arrives gradually.
- Ignoring the “no data” message. It usually means low traffic, not a problem; judge performance from lab tests and your own RUM instead.
- Looking only at the homepage. Product, blog and location templates often perform very differently.
How to act on it
Open PageSpeed Insights for your main templates and read the top section, which shows field data, before the lab score below it. Then check the Core Web Vitals report in Search Console, which groups failing URLs by issue so you can see whether one template is responsible for most of the problem.
Use lab tools to find the cause, fix it, and then watch the field figures over the following month to confirm the change worked for real visitors. Diagnosing which templates fail in the field and why is a standard part of my technical SEO service.