Lab data vs field data: why your speed scores differ

An analogy that helps

Think of a car. Lab data is a test drive on a closed track: the same driver, the same road, the same weather every time. It is repeatable, and it is the right way to find out why the car pulls to the left. Field data is the fuel use and breakdown record of every driver who owns the car, in real traffic and real weather. It says how the car actually does, but it cannot tell you why.

Website speed has the same split. A lab tool loads your page once under conditions it controls. Field data records what real people experienced, whatever their phone, connection and habits. Google's Core Web Vitals are judged on the second kind.

Field data: what really happened

For the Core Web Vitals the field data comes from the Chrome UX Report (CrUX; see the CrUX guide for who is in it). Chrome measures the experience of its users as they browse, and Google aggregates it. You see it in PageSpeed Insights, in Search Console and through the CrUX API.

What to know about it:

• It is a sample, not everyone. It includes Chrome users on desktop and on Android who have turned on usage statistics and history sync. Visitors using Chrome on an iPhone, Edge, or an app's built-in browser are not in it.
• It is a window. The numbers cover the last 28 days and are updated daily. A fix you made yesterday is a small part of the data.
• It is a distribution. Google reads the 75th percentile: the result that three out of four visits were as good as or better than.
• It needs traffic. A page needs a minimum number of visitors, which Google does not publish, to have data of its own. Otherwise you see data for the whole site, or none.
• It follows the page, not the route. Each metric is measured for a page load. On a single-page app, moving between screens inside the app has traditionally not counted as a new page, so the numbers describe the page the visitor landed on. Chrome has been experimenting with measuring those transitions.
• Frames count for the page. A widget embedded in an iframe is not reported as a page of its own, but its layout shifts count against the page that contains it.

What it cannot do is explain itself. It tells you that LCP is slow for a quarter of mobile visitors; it does not tell you whether the cause is a big image, a slow server or a script.

Lab data: what a controlled test shows

Lighthouse, which runs behind PageSpeed Insights, loads the page in Chrome with a fixed setup. On the default mobile test, that is a screen 412 pixels wide, a connection simulated at 1.6 megabits per second with 150 milliseconds of latency, and a processor slowed four times. The desktop test uses a larger screen, 10 megabits per second with 40 milliseconds of latency, and no slowdown.

What is good about it:

• It is fast. You get an answer in under a minute, the moment you change something.
• It is repeatable enough to compare. Same setup, so a before and after test means something.
• It explains. It lists the requests that blocked the page, the images that were too big, the scripts that kept the main thread busy.
• It works before launch. It does not need any visitors, so you can test a page that is not live yet.

Lighthouse turns its timings into a 0 to 100 score, which is a summary of one lab run and nothing more.

What it leaves out:

• It is one visitor. One device and one network. Your real visitors have hundreds of combinations, and many are worse than the test.
• It does not behave like a person. It does not scroll, hover, open the menu or tap the cookie banner. Anything that happens after the load is missing, including most layout shifts that come from scrolling and all interaction delays.
• It usually starts cold. Lighthouse clears stored data before a run, so a lab test sees a first visit. Many real visits are repeat visits with cached files.

Why the two disagree

If a page scores 98 in the lab and fails in the field, or the lab shows a poor LCP while the field is good, one of these is usually the reason.

1. The visitors' devices are slower than the test. A phone from a few years ago, with other apps open, runs JavaScript much slower than the simulated one.
2. The networks are worse. Rural connections, crowded public wifi and roaming are all slower than 1.6 megabits with 150 milliseconds of latency, which Lighthouse describes as roughly the 75th percentile of 4G.
3. Location. A server far from the visitor is slower for them. A test from one place hides it.
4. State. Logged-in users, shopping carts, personalized content and consent banners change what the page does. A test sees the plain version.
5. Behavior after the load. Scrolling can bring in lazy-loaded content that shifts the layout, and taps trigger the code that INP measures. The lab does not do either.
6. Real pages vary. A/B tests and rotating ads give each visitor a different page. Lighthouse's own documentation lists this as an unremovable source of variation.
7. Different pages in the sample. Field data for a site may mix the home page, product pages and the blog. A lab test looks at one URL.
8. Different time. The field numbers are an average of the last four weeks. The lab test is now. If you just fixed something, the lab will show it and the field will not for weeks.

Which one to trust for what

What to do when they disagree

The lab looks good and the field is poor. This is the common and more serious case. The test is easier than real life, so make it harder. Slow down the CPU and network further in Chrome DevTools. Test on a real, older phone. Scroll the page, open the menu, tap the buttons. Try from another country if your visitors are there. Look at which pages the field data covers. Then compare what you find with the field numbers.

The lab looks poor and the field is good. Real visitors are fine, perhaps because many of them already have the files cached, or are on faster devices than the test assumes. This is a good place to be. Use the lab to find improvements, because the same fixes still help your slowest visitors, but you are not failing.

Both are poor. Start with the lab. The causes it lists are the same ones your visitors are suffering from.

Both are good. Nothing is urgent. Test again every few months and after each large change.

Common mistakes

• Chasing a lab score of 100 while the field data fails the Core Web Vitals.
• Ignoring a poor field result because the lab test looks fine.
• Comparing a lab number from today with a field number from the last four weeks.
• Testing only from the office, on fast wifi and a new laptop.
• Testing the home page and assuming the other pages are the same.

Check your own page

Run the free audit and compare the two parts of the result; how to measure Core Web Vitals shows where each one is read. Note which of the three metrics is weakest in the real-visitor data and which in the lab data. If they point at different problems, the difference is your next question, and the list above is where to look for the answer.

Sources

• Chrome UX Report methodology: who is in the field data, the 28-day window, page and site eligibility.
• Optimize Cumulative Layout Shift: why lab and field CLS differ.
• Lighthouse score variability: why one lab test is not another.
• Core Web Vitals and single-page applications: how route changes are treated.