Two ways to measure the same page
Imagine checking how long a commute takes. You could drive the route once on a quiet Sunday with a stopwatch, or you could collect the actual journey times of everyone who commutes that way over a month. Both are legitimate measurements, and they will almost never match. Speed data works the same way.
- Lab data comes from a test: a tool loads a page in a controlled setup, with a defined device and network, and records what happened.
- Field data comes from real visitors: their browsers report how the page performed for them, and the results are combined over time.
Other names you may see for these are synthetic data and real-user data.
What lab data is good for
A lab test is repeatable. You can run it right now, on a page that has not been published, without waiting for visitors. Because the conditions are fixed, a change in the result is more likely to be caused by a change in the page.
That makes lab data useful for:
- Diagnosis. A test usually produces a breakdown of what loaded, in what order and what delayed the first view. This points to causes such as a heavy image or a blocking script.
- Checking a fix. Test before and after a change under the same settings.
- Pre-launch checks. You can test a staging site or a new template before any visitor sees it.
- Comparing versions. Two page designs can be compared on equal terms.
What lab data cannot tell you
A lab test is one visit by one imaginary visitor. It does not know:
- What devices your visitors actually use. Your test may simulate a mid-range phone; many visitors will be on better or worse ones.
- What networks they are on. Real connections vary widely, and fluctuate during a visit.
- Whether the content is cached. A first-time visitor downloads everything; a returning one may not.
- What they do. Lab tests mostly load the page and stop. Real people scroll, tap menus, open forms and interact with scripts, which affects responsiveness measures.
- Where they are. Distance from the server and the content delivery setup change results by location.
- Which version of the page they see. Personalization, advertising, consent banners and logged-in states can all alter the page.
What field data is good for
Field data shows what actually happened to real people. That makes it the better judge of whether a page is delivering a good experience. For the Core Web Vitals measures, real-visitor data is generally regarded as the main evidence, because it reflects the full range of devices, networks and behavior.
It also reveals problems that lab tests miss, such as a script that only misbehaves on certain phones, or slowness that appears only for visitors far from your server.
What field data cannot tell you
- It is slow to respond. Field reports are usually averaged over a window of weeks, so a fix may take a while to show up.
- It needs enough visitors. Pages with low traffic may have no field data at all, or only data grouped across many pages of the site.
- It does not explain itself. It tells you that the main content is slow for many visitors, not why. You need a lab test to investigate.
- It is reported as a summary. Often it is the value that most visitors fell within, such as the 75th percentile, which hides what the slowest experiences looked like.
Why the two disagree
A few typical reasons:
- The lab device is faster or slower than reality. If your test setup is more powerful than typical visitors’ phones, the lab looks better than the field. If it is deliberately throttled, it may look worse.
- Caching. Returning visitors load less. A lab test usually simulates a first visit, so it can look worse than the field for pages with many repeat visitors.
- Interaction. Lab tests may not click anything. A page can score well in a test and still feel sluggish once people use it.
- Layout shifts later in the visit. Real visitors scroll and trigger content that appears after the lab test has ended.
- Different pages. Field data may combine many pages with the same template, while a lab test looks at one URL.
- Different timing. The lab test is today’s page; field data may include weeks before your last fix.
- Random variation. Servers and networks fluctuate. Two lab runs a minute apart can differ.
None of this means one source is wrong. It means they answer different questions.
A sensible way to use both
- Start with field data if you have it. Look at which pages or page types are doing worst for real visitors, and on which devices.
- Reproduce the problem in the lab. Test those pages on a setup resembling your slow cases, such as a modest phone with a slower connection.
- Diagnose and change one thing at a time. Use the lab breakdown to identify causes. Repeat the test a few times and look at the typical result, not the best one.
- Confirm in the field. After the fix is live, wait for field data to catch up before judging success.
- Keep notes. A simple change log of what was modified and when makes it easier to line up improvements with later results.
If field data is not available for your site, rely on repeated lab tests on realistic settings, and consider collecting your own performance measurements from visitors through your analytics setup. Be careful to collect only what you need.
Reading numbers calmly
A single score from a single tool should never be the whole story. When reports conflict, ask what each one measured, on what device and over what period. In an audit it is usually enough to say something like: “Field data suggests the main content is slow on mobile for many visitors; lab tests point to a large top image and several scripts as the likely causes.” That sentence is more honest, and more useful, than any single number. The broader question of how to read figures sensibly is also a theme in metric interpretation.