Lab data is page performance measured by loading a page in a controlled test, with a set device, network speed and location, rather than collected from real visitors. Tools such as Lighthouse and the diagnostic section of PageSpeed Insights produce it.
How lab data works
A testing tool opens the page in a browser under fixed conditions. For mobile tests it typically emulates a mid-range phone on a throttled connection, so the result reflects a slower experience than a new laptop on office broadband. It records timings as the page loads, including First Contentful Paint, Largest Contentful Paint, Cumulative Layout Shift and Total Blocking Time, and flags what slowed each one down.
Because nobody clicks or types during the test, lab tools cannot measure Interaction to Next Paint, the responsiveness metric in Core Web Vitals. Total Blocking Time stands in as a proxy: it measures how long the browser’s main thread was too busy to respond during loading.
The alternative is field data, gathered from real Chrome users visiting your site over the previous 28 days. Google’s Core Web Vitals assessment, both in Search Console and in its page experience signals, uses field data, not lab results.
Why it matters
Lab data is what you can measure today. It needs no traffic, so it works on a staging site before launch, on a page you published this morning, or on a small business site that does not get enough visitors to have field data at all. It is repeatable, which makes it the right tool for testing whether a fix worked, and it explains causes in a way field data cannot.
It is also one scenario, and real visitors are many. A London audience on fast connections may experience a page far better than the throttled lab test suggests. Equally, a page can look fine in the lab and poor in the field. One reason is particular to UK and EU sites: a lab test does not click the cookie banner, so analytics, chat widgets and marketing tags that load only after consent never appear in the test, yet they load for every real visitor who accepts.
Common mistakes
- Chasing a perfect lab score instead of fixing what real visitors experience.
- Comparing single runs, when results naturally vary from one test to the next.
- Testing only on desktop when most visitors arrive on phones.
- Testing while logged in to WordPress, which loads the admin bar and other extras visitors never see.
- Running DevTools tests on a fast laptop without throttling and concluding the site is quick.
- Assuming the lab score is what Google uses for rankings.
How to act on it
Use field data to decide what needs fixing and lab data to work out why. If Search Console reports slow mobile pages, test a representative page in PageSpeed Insights or Lighthouse, run it three to five times and look at the middle result. Read the diagnostics for the element and resources behind each slow metric.
Keep the test settings the same each time, so a change in the numbers reflects a change to the page rather than to the test. Test fixes in the lab on a staging copy before release, then watch field data afterwards. Because it is a rolling 28-day window, real improvements take a few weeks to show fully. Interpreting both sets of data and turning them into a prioritised fix list is part of my technical SEO work.