PageSpeed vs Real User Metrics: Why Lab Scores and Field Data Disagree
PageSpeed Insights runs two different tests on the same page and they regularly disagree. Here is why lab scores diverge from CrUX field data and which one matters.
Updated 7 min read
Every agency has had this conversation. The client sends a screenshot of their PageSpeed Insights score — either a triumphant green 95 or a panicked red 38. Either way, the conversation is usually based on the wrong number.
PageSpeed Insights runs two very different tests and puts the results on the same page. One is a lab simulation. The other is real visitor data. They measure different things, under different conditions, and they regularly disagree. If you are reporting the lab score to clients as "their site's performance," you are telling a half-truth that will eventually catch up with you.
Lab vs Field: Two Different Measurements
The lab score comes from Lighthouse. It loads your page in a simulated environment: a mid-tier phone on a throttled 4G connection, with a fixed viewport, no extensions, no cookies, no logged-in state. It measures a handful of metrics and produces a weighted score from 0 to 100.
The field data comes from the Chrome User Experience Report (CrUX). Google collects performance data from real Chrome users who have opted into usage statistics. It aggregates 28 days of actual page loads from actual devices on actual networks, then reports the 75th percentile (p75) for each Core Web Vital. There is no single score — just the slowest-quarter boundary for LCP, CLS, and INP.
Lighthouse tells you "how does this page perform under controlled conditions?" CrUX tells you "how does this page perform for the people who actually visit it?" Those are not the same question.
Why They Disagree
The divergence is not a bug. It is a consequence of how different the two environments are.
Lab vs Field Environment Differences
| Factor | Lab (Lighthouse) | Field (CrUX) |
|---|---|---|
| Network | Simulated slow 4G | Everything from 5G in Seoul to spotty Wi-Fi in a coffee shop |
| Device | One emulated mid-tier phone | The actual mix: iPhones, Pixels, budget Androids, desktops |
| Caching | Cold load every time — no cache, no service worker | Includes return visits with cached assets and pre-connected sockets |
| Third parties | Loaded in a controlled way | GTM firing 14 tags, chat widgets, A/B tools injecting CSS at runtime |
| Geography | Single location (usually US) | Everywhere your visitors actually are |
LCP: The Metric That Diverges Most
Largest Contentful Paint measures when the main content becomes visible. In the lab, LCP is nearly deterministic — the viewport is fixed, the hero image is the same every time, fonts load on the same timeline.
In the field, LCP depends on what is "largest" for each visitor. Different screen sizes change which element qualifies. Responsive images serve different file sizes. A visitor on a 375px iPhone sees a completely different layout than someone on a 1440px desktop, and the LCP element might differ too.
It is common to see a lab LCP of 1.8 seconds and a field LCP of 3.2 seconds on the same page. That gap is not because Lighthouse is wrong — it is measuring one scenario out of thousands.
CLS: Layout Shift Is Context-Dependent
Cumulative Layout Shift measures visual instability. Lighthouse catches shifts during the initial page load. But many real-world layout shifts are triggered by user interaction: scrolling loads lazy content, a cookie banner animates in after three seconds, an accordion pushes the footer down.
CrUX captures the full session's CLS, including shifts that only happen when someone actually uses the page. The result is that lab CLS tends to be lower than field CLS. The lab sees the page at rest; real visitors see it in motion.
INP: The Metric Lab Cannot Fully Measure
Google replaced First Input Delay with Interaction to Next Paint in March 2024. INP measures how long the browser takes to respond to any interaction throughout the entire page visit — not just the first one.
That "throughout the entire visit" part is the key. Lighthouse can estimate INP by simulating a few interactions, but it cannot replicate a real visitor clicking buttons, opening dropdowns, scrolling through feeds, and triggering JavaScript-heavy re-renders across a five-minute session. If your JavaScript is heavy on interaction handlers (SPAs, complex forms, dynamic filtering), your field INP will almost certainly be worse than anything Lighthouse reports.
When to Use Each
This is not a "lab bad, field good" situation. Both have a role, and using the wrong one for the wrong purpose is where agencies get into trouble.
Lab vs Field: When to Use
| Use Lab (Lighthouse) For | Use Field (CrUX) For |
|---|---|
| Development and debugging — controlled before/after testing | Client reporting — what visitors actually experience |
| Identifying specific bottlenecks — which resource blocked rendering | Tracking trends over time — 28-day rolling window smooths noise |
| Pre-launch audits — no field data exists yet | Google's ranking signal — Core Web Vitals uses CrUX, not lab scores |
How to Report Performance Honestly
Show both, label which is which. "PageSpeed score: 91 (lab)" and "LCP p75: 3.2s (field, mobile)" are two different things and the client should see both. The lab score is useful as a quality target for the development team. The field data is what Google actually uses.
Trend field data, do not snapshot it. A single CrUX reading is one point on a 28-day rolling average. SyncingBeam's site-health connector stores CrUX history — up to 25 weeks of rolling periods — so the dashboard shows whether field LCP is trending down after a CDN change or just bouncing around its usual range.
Name the device split. A client whose desktop Core Web Vitals pass and mobile fails needs to know that, and they need to know it is the mobile experience that affects most of their ranking.
Be honest about lag. CrUX is a 28-day rolling average. A fix deployed last week will not be fully reflected for four weeks. Tell the client this before they wonder why the number has not moved.
For more on structuring reports around these metrics, see our SEO reporting guide and the data freshness article.
Practical Takeaways
Performance Reporting Checklist
Never report only the lab score. Always pair it with CrUX field data.
Watch for lab/field divergence — a big gap means the real environment differs from the simulation.
Track field data over time. Monthly CrUX snapshots show trends; quarterly reviews show whether optimization work is actually landing.
Use lab for debugging, field for reporting. Lighthouse pinpoints what to fix; CrUX confirms whether the fix worked.
If the client's site lacks enough traffic for page-level CrUX data, say so honestly rather than substituting the lab score.
Automate the pull — running PageSpeed manually and copying numbers into slides wastes time better spent on actual optimization.
Frequently Asked Questions
Why does my PageSpeed score differ from Core Web Vitals status in Search Console?
The PageSpeed score is a lab simulation from Lighthouse. Search Console's Core Web Vitals assessment uses CrUX field data from real Chrome users over 28 days. They measure the same page under very different conditions, so disagreement is common and expected.
How long does CrUX take to reflect a performance fix?
CrUX uses a 28-day rolling window at the 75th percentile. A fix deployed today will take approximately four weeks to be fully reflected in the data, as old visits gradually cycle out of the window.
What is the traffic threshold for CrUX data?
A URL needs a minimum number of Chrome visits in 28 days to produce a statistically meaningful sample. Low-traffic pages will show "not enough data" in PageSpeed Insights. Origin-level data (aggregating all pages on the domain) has a lower effective threshold because it pools traffic.
Does Google use the lab score or field data for rankings?
Google uses CrUX field data for its Core Web Vitals ranking signal. A page passes when its p75 LCP is under 2.5 seconds, p75 INP is under 200ms, and p75 CLS is under 0.1. The Lighthouse performance score is not a ranking signal.
How does SyncingBeam track CrUX data over time?
SyncingBeam's site-health connector pulls CrUX history (up to 25 weeks of rolling 28-day periods) and stores each period with its start and end dates. This creates a trend line showing whether field performance is genuinely improving or just fluctuating.