Lighthouse vs CrUX: why your lab score and real score disagree
Lighthouse is a lab test: it loads your page once, on a simulated mid-range phone with a throttled connection, and scores that one run. CrUX, the Chrome User Experience Report, is field data: the real Core Web Vitals of actual Chrome visitors over the last 28 days, reported at the 75th percentile. When the two disagree, believe the field data, because per Google's own page experience documentation the ranking signal comes from real-user data, not a lab run.
The confusion: "Lighthouse says I am fine, so why is my site slow?"
This is one of the most common questions owners bring us. They ran a test, got a green score or a fast number, and cannot understand why Google still treats the page as slow, or why real visitors complain. The answer is that they measured the lab, and Google measured the field. They are two different numbers, and they were never meant to match.
The two numbers, side by side
Lab data (Lighthouse):
- One synthetic load, on a simulated device, in a controlled environment.
- Perfectly repeatable, which makes it excellent for debugging a change.
- Blind to your real audience: their phones, their networks, their locations.
- Cannot measure Interaction to Next Paint properly, because no real person is tapping.
Field data (CrUX):
- Real Chrome users over a rolling 28-day window.
- Reported at the 75th percentile, so it reflects a bad experience one visitor in four is having, not your best case.
- The data Google's ranking systems actually use.
- Only exists if your site gets enough Chrome traffic to be in the dataset. Most small sites are not.
Why they disagree
Three reasons cover almost every gap. First, the device: you tested on a fast laptop, your visitors are on older phones. Second, the network: your office fibre is not the mobile connection a customer uses on the move. Third, the percentile: a lab run reports one number, while CrUX reports the 75th percentile, deliberately weighting toward the slower experiences real people have. A page can look great in the lab and still fail in the field because a quarter of real loads are slower than your one clean test.
How to use each one correctly
Use them for what each is good at. Field data is your verdict: it tells you whether you have a problem worth fixing and whether a fix worked, though it lags by weeks because of the 28-day window. Lab data is your workshop: it is instant and repeatable, so you use it to confirm the mechanism moved today, the LCP element changed, the blocking script is gone, before waiting for the field to catch up. Ship the fix, confirm it in the lab, then watch the field data over the following weeks.
Where AuditLamp fits
We do not run Lighthouse. We read your HTML source and flag the patterns that most often cause bad vitals, the lazy-loaded hero, the missing image dimensions, the render-blocking scripts, so you know what to change before you ever open a lab tool. When CrUX field data exists for your site, we show it too, and when it does not, we say so plainly rather than invent a score. That honesty is the whole point: see exactly what the checks are on the Core Web Vitals hub.
Verify it yourself
Run your URL through PageSpeed Insights, which shows both numbers on one screen: field data at the top, lab data below. If reading that report is new to you, we walk it top to bottom in how to read PageSpeed Insights. When you are ready to fix the causes, start with a slow LCP, a slow INP, or layout shift, then paste your link into the full AuditLamp audit to see the source-level causes in one pass.