Field data is what real users experienced on your site. Lab data is what a single simulated test measured under controlled conditions. Google evaluates Core Web Vitals with field data from the Chrome UX Report (CrUX): the 75th percentile of real Chrome visits over the previous 28 days, where good means LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1. Lab tools like Lighthouse are for diagnosing problems and testing changes before they reach users. Use field data to decide what to fix, and lab data to work out how.
What is field data?
Field data, also called real user monitoring (RUM), comes from actual visits. The best-known source is CrUX, which aggregates performance data from Chrome users who opted in to share usage statistics. It is the data behind the Core Web Vitals report in Search Console and the “Discover what your real users are experiencing” section at the top of PageSpeed Insights.
Keep four things in mind when you read it:
- It reports the 75th percentile. A page passes if at least 75% of visits meet the threshold, so a fast median does not hide a slow tail.
- It is a rolling 28-day window. A fix you deploy today will take weeks to be fully reflected.
- It is available at origin level and, when there is enough traffic, at URL level. Low-traffic pages may show no data, or fall back to origin data.
- It reflects your real audience: their devices, networks, locations and the way they interact with the page.
You can also collect your own field data with Google’s web-vitals JavaScript library or a RUM service. Then you get data for every page and every browser that supports the APIs, plus details CrUX does not expose, such as which element was the LCP or which interaction was slow.
What is lab data, and what is it good for?
Lab data comes from a controlled test: one page load, on a defined device profile and network, from one location. Lighthouse, which powers the lower section of PageSpeed Insights, is the most common example. On mobile it emulates a mid-range phone on a throttled connection. WebPageTest and the Performance panel in Chrome DevTools are lab tools too.
The big advantage is that lab data is reproducible. You can run the same test before and after a change and see the difference within minutes. It also gives you diagnostics that field data cannot: a waterfall, a main-thread trace, the list of render-blocking resources, the LCP element and how long each phase took.
What it cannot tell you is what your users experience. It is one device, one network and one cold page load, with no real interaction.
Field vs. lab, side by side
| Aspect | Field data (CrUX, RUM) | Lab data (Lighthouse, WebPageTest) |
|---|---|---|
| Source | Real visits from real users | One simulated or controlled page load |
| Used by Google for Core Web Vitals | Yes | No |
| Time to reflect a change | Up to 28 days in CrUX | Immediately |
| INP | Measured from real interactions | Not measurable; TBT is used as a proxy |
| CLS | Shifts across the whole visit | Only shifts during the test load |
| Diagnostics | Limited in CrUX; richer with your own RUM | Detailed waterfall, traces and audits |
| Best for | Deciding what to fix and confirming results | Finding causes and testing fixes |
Why do the two disagree so often?
I hear the same question in audits all the time: “PageSpeed says 45, but Search Console says my pages are good. Which one is right?” Both are. They measure different things.
These are the usual reasons for the gap:
- Devices and networks. If your audience mostly uses recent phones on fast connections, real LCP can be much better than the lab’s throttled profile. If your audience uses older Android devices, the opposite happens.
- Caching. Lighthouse simulates a first visit. Real users often come back with a warm browser cache, and many hit a page cache or CDN that a lab run on an uncached URL never touched.
- Interactions. INP depends on what users click and when. A lab test that never clicks cannot measure it, and Total Blocking Time only suggests where the risk is.
- Layout shifts after load. Lazy-loaded ads, cookie banners and infinite scroll cause CLS later in the visit, which a lab load never sees.
- Score vs. metrics. The Lighthouse performance score is a weighted lab summary. It is not a Core Web Vitals assessment, and Google does not use it for ranking.
The Lighthouse score is a test result. The CrUX 75th percentile is the experience. Optimise for the experience and use the test to get there.
How should you use both in practice?
This is the workflow I use and teach:
- Start with field data. Check CrUX in PageSpeed Insights or Search Console for the origin and your key templates. Find out which metric fails and on which pages.
- Reproduce it in the lab. Run Lighthouse or WebPageTest on a representative URL with a realistic device profile, and use the diagnostics to find the cause: slow TTFB, render-blocking CSS, an unoptimised hero image, a heavy third-party script.
- Fix one thing at a time on staging and compare lab runs before and after. Run several tests, not one, because lab results vary.
- Deploy and wait. Watch your own RUM for early signals, and give CrUX the full 28-day window before you judge the result.
- Keep monitoring. Plugins, themes and marketing tags change all the time, and field data is where regressions show up first.
For INP, lean on field data and real interaction testing. Record a trace in DevTools while you click the menu, the filters, add-to-cart and the form fields users actually touch, and look for long tasks on the main thread.
So don’t chase a lab score for its own sake. Field data tells you where you stand, lab data tells you why, and together they prove that a change made the site better for the people visiting it.