You run your homepage through PageSpeed Insights. At the top, a green tick: “Core Web Vitals Assessment: Passed”. Scroll down, and the performance score is an orange 52 with a list of problems. Which one is the truth? Is the site fast or slow?
Both are telling the truth, about different things. The top block is field data, the bottom is lab data, and understanding field data vs lab data is what stops you either panicking over a score that does not matter or ignoring a problem your customers really have.
Two numbers, two different questions
The simplest way to put it:
- Field data answers “what have real visitors experienced on this page over the past few weeks?”
- Lab data answers “what happens when we load this page once, right now, under fixed test conditions?”
One is a record of the past from many people. The other is a controlled experiment with one imaginary person. Neither is a better version of the other; they are tools for different jobs.
| Field data (CrUX) | Lab data (Lighthouse) | |
|---|---|---|
| Who | Real Chrome users who share usage statistics | One automated test visit |
| When | The previous 28 days, rolling | The moment you click Analyse |
| Device | Whatever phones and computers your visitors use | An emulated phone or desktop with set speed limits |
| Interactions | Real taps and clicks, so INP is measured | None, so INP cannot be measured |
| Available for | Pages and sites with enough traffic | Any public page |
| Best for | Judging the real experience, Search Console | Debugging, testing a change straight away |
Field data: CrUX in plain terms
CrUX stands for the Chrome User Experience Report. When people use Chrome with usage statistics sharing turned on, the browser records how pages loaded and responded for them. Google aggregates this into a public dataset.
Things worth knowing about it:
- It is a 28-day rolling window. Today’s figure includes visits from almost a month ago. Changes you make take weeks to show fully.
- It is reported at the 75th percentile. The figure is the point three quarters of the way through your visits, sorted fastest to slowest, which deliberately includes your slower visitors.
- It needs traffic. Pages or sites without enough eligible visits have no published data. You will see “no data” rather than a number.
- It has two levels. PageSpeed Insights can show data for the exact URL and for the origin (your whole domain). The origin figure blends every page together.
- It is split by device. Mobile and desktop are reported separately.
This is the data behind the Core Web Vitals assessment at the top of PageSpeed Insights and behind the whole of Search Console’s Core Web Vitals report. It is what Google uses when it refers to your site’s page experience. A refresher on the metrics themselves is in our Core Web Vitals overview.
Lab data: Lighthouse in plain terms
Lighthouse is the testing engine inside PageSpeed Insights and Chrome DevTools. When you run a test, it loads your page once on an emulated device with the processor and network deliberately slowed to represent a typical phone, measures what happens, and produces the performance score out of 100 along with a list of opportunities and diagnostics.
Its strengths are control and detail. Run it after a change and you see the effect immediately. It names the LCP element, lists render-blocking files, flags images without dimensions and points at long JavaScript tasks.
Its limits are equally clear:
- It is one visit. Results vary between runs, sometimes noticeably, and for reasons covered in why your PageSpeed score keeps changing.
- Nobody taps anything, so it cannot measure INP. It reports Total Blocking Time as an indicator of how busy the page is during load.
- It only sees the start of the visit. Layout shifts that happen after scrolling, or ads that fill later, may never appear.
- It tests from a server with a clean cache, not from your visitors’ homes or their partly cached browsers.
Why field data vs lab data so often disagree
If you have ever seen a passing field result above a poor lab score, or the reverse, one of these is usually why.
Your visitors’ devices are faster or slower than the test
Lighthouse’s emulated phone is meant to be modest. If most of your visitors use recent phones on good connections, the field will look better than the lab. If many use older Android phones on patchy mobile data, the field may look worse.
Real visitors have warm caches
Returning visitors already have your CSS, fonts and logo stored in their browser. Lighthouse starts cold every time. A site with lots of repeat visitors often has better field LCP than lab LCP.
The lab cannot see interactions
A page can score well in the lab and still have poor field INP, because the slow part is what happens when someone opens the menu or changes a product option. The lab never tries.
Time
Field data includes the past 28 days. If you fixed something last Tuesday, the lab already shows the improvement while the field is still averaging in the old, slow visits.
Your audience is not the test’s audience
Lighthouse in PageSpeed Insights runs from Google’s servers, wherever the test happens to be routed. Your real visitors might all be in one city near your host, or spread across continents far from it. Distance changes how long every request takes, and the lab cannot reproduce your particular mix of locations and networks. A shop selling mainly to one country, hosted in that country, may well see field numbers that look kinder than the lab.
Different pages are being compared
If the URL has no field data of its own, PageSpeed Insights may show origin-level data instead. You are then comparing one page’s lab test with your whole site’s real experience.
CrUX vs Lighthouse: which to trust for what
A practical rule of thumb for each common question:
- “Are my visitors having a good experience?” Field data. That is literally what it records.
- “Will Google see my pages as passing Core Web Vitals?” Field data, since Search Console and the assessment are built on it.
- “Did the change I just made work?” Lab data, run several times before and after. Then confirm in the field a few weeks later.
- “Why is LCP slow?” Lab data, for the diagnostics and the breakdown of the LCP element.
- “Is this new page, with no traffic yet, going to be fast?” Lab data, plus testing on a real phone, because there is no field data to look at.
- “Is my INP problem fixed?” Your own testing in DevTools for the immediate check, field data for the verdict.
The mistake to avoid is treating the lab score as the target. A score of 95 that the owner fought for, with field INP still poor, helps nobody. Equally, a passing field result does not mean you should ignore a lab report pointing at a three-megabyte hero image; the field may simply be flattered by fast devices or repeat visits.
Using both together
A routine that respects what each is good for:
- Start with field data in Search Console or PageSpeed Insights to find which metric is failing, on which device, on which kind of page.
- Use lab data to investigate one example page: what is the LCP element, what is blocking, what is shifting. If the lab half of the report is unfamiliar, a section-by-section reading of PageSpeed Insights helps.
- For network-level detail, open the page in Chrome DevTools; our post on checking page load in the DevTools network tab shows how.
- Make one change, re-run the lab test several times and compare the median.
- Record the date, then check field data again after a few weeks.
Some sites go one step further and collect their own real-user measurements with a small script (Google publishes a web-vitals JavaScript library for this) and send them to their analytics. That gives you field data for pages too quiet for CrUX, and faster feedback after a change. For most small business sites, CrUX plus careful lab testing is enough.
Field and lab numbers are only part of how you judge speed. For the rest, from hosting to scripts, the guide on how to make a website load faster brings it together.
Frequently asked questions
Can my field data pass while some visitors still find the site slow?
Yes. Passing means at least three in four recorded visits met the threshold, so up to a quarter can still be slower. Visitors who do not use Chrome, or do not share usage statistics, are not in the data at all. A pass is a good sign for most of your audience, not a promise that everyone has a fast visit.
Does Google use my Lighthouse score for ranking?
Google’s documentation describes Core Web Vitals in terms of real-user field data, and the Lighthouse performance score is not part of that. The lab score is a diagnostic tool to help you find problems. Improving it often improves real experience too, but the number out of 100 itself is not what Search Console or the assessment reports.
Is testing on my own phone field data or lab data?
It is closer to lab data, because it is one visit on one device that you control, even though the device is real. It is very useful, especially on an ordinary mid-range phone, but it does not represent your visitors as a whole. Field data only comes from aggregating many real visits.
Sorting the real problems from lab noise is the audit stage of our speed optimisation work. You get the findings in plain language with a prioritised list, and you decide what goes ahead.
Next in this series: Core Web Vitals Assessment Failed? What It Means
