Measure website speed with two kinds of data: field data from real visitors, which tells you what people actually experience, and lab data from a controlled test, which helps you find and fix causes. When the two disagree, trust field data for the verdict and use lab data for the diagnosis.
Two kinds of measurement
Google’s web.dev guidance describes the difference clearly. Lab data comes from a controlled test: one device, one network, one location, usually with an empty cache, run through Lighthouse. It is repeatable, which makes it useful for debugging. Field data comes from real users across many devices, networks and locations. It is a distribution, and tools typically report the 75th percentile. See Why lab and field data can be different.
| Lab data | Field data | |
|---|---|---|
| Source | Simulated load in a test environment | Real visits by real users |
| Typical tools | Lighthouse, PageSpeed Insights lab section, browser dev tools | CrUX, PageSpeed Insights field section, Search Console reports, your own real-user monitoring |
| Strength | Repeatable, detailed, works before launch | Reflects real experience, what users actually get |
| Weakness | One scenario only | Slow to change, needs enough traffic, limited detail |
| Best use | Debugging and checking fixes | Judging how the site really performs |
What PageSpeed Insights shows
PageSpeed Insights combines both. Google’s documentation says field data comes from the Chrome User Experience Report (CrUX) and covers real users over the previous 28-day collection period, rated Good, Needs Improvement or Poor using the 75th percentile. If a page does not have enough data, PageSpeed Insights falls back to origin-level data, and if the origin also lacks data, no real-user data is shown. The lab section is a Lighthouse run: mobile tests simulate a mid-tier Moto G4 on a mobile network, and desktop tests use an emulated desktop with a wired connection. See About PageSpeed Insights.
That explains several confusing situations:
- A strong lab score but weak field data. Real users may have slower phones and networks than the simulation.
- A weak lab score but good field data. Returning visitors may benefit from cached resources, and back/forward cache restores can be nearly instant. The web.dev article notes lab tests generally capture neither.
- No field data at all. A new or low-traffic page may not have enough CrUX data, so you will only see lab results.
- Changes not showing up. The 28-day window is a trailing period, so improvements appear gradually.
Why individual metrics differ
The web.dev article also explains metric-specific causes. Largest Contentful Paint can differ because the largest element varies by screen size, login state, A/B tests or fonts. Interaction to Next Paint depends on when real users interact, which a lab cannot predict, so a page can have good Total Blocking Time and still have poor INP. Cumulative Layout Shift in the field counts shifts that happen later, such as during scrolling or after interaction, and includes personalised content a lab may not load. If you need background on the metrics themselves, our guide to website speed and Core Web Vitals for business covers what they mean.
Know the limits of CrUX
CrUX is valuable, but it is not the whole picture. Google’s article on CrUX and RUM differences says CrUX covers only Chrome users who opted in, only public and sufficiently popular sites, and uses a fixed 28-day sliding window. It also cannot segment data for debugging in the way your own real-user monitoring can. If you need to compare the two, filter your own data to Chrome, the same device type, the 75th percentile and a 28-day window, and focus on trends rather than exact matches.
A practical testing process
- Check field data first. Look at PageSpeed Insights or Search Console for your key templates: home page, a service or product page, a content page. Note which metrics are not Good.
- Identify the pattern. Is it all pages or one template? Mobile or desktop?
- Use lab tools to find causes. Run Lighthouse on the affected pages and read the diagnostics: large images, render-blocking scripts, heavy third-party tags, slow server response.
- Test on real, modest devices. A mid-range phone on a normal connection is more honest than a developer laptop.
- Fix one thing at a time and re-test. Lab results confirm the fix quickly.
- Wait for field data to catch up. Because of the 28-day window, give it time before judging the outcome.
- Repeat after changes. New plugins, tracking scripts, fonts and images can quietly undo improvements.
Common mistakes
- Chasing a perfect Lighthouse score. Google’s own guidance says to prioritise field data because it reflects what users experience.
- Testing one run and treating it as truth. Lab results vary between runs, so repeat tests and compare trends.
- Testing only the home page. Template-level problems often hide on product, booking or blog pages.
- Ignoring third-party scripts. Chat widgets, analytics and ad tags are a frequent cause of slow interaction.
- Comparing tools without understanding their sources. Different tools use different conditions, so numbers will not match.
Speed is partly a build decision
Testing finds problems, but the architecture sets the ceiling. Astro versus WordPress discusses how site-building choices affect performance, and if you are changing platforms, planning a website redesign without losing SEO value explains how to keep your gains through the move.
Where Radiance Impact fits
Radiance Impact’s Technology division builds and maintains business websites with performance in mind. To discuss testing or improving your site’s speed, see /technology or contact us.
Sources
- Why lab and field data can be different, web.dev
- About PageSpeed Insights, Google for Developers
- Differences between CrUX and RUM data, web.dev
