Lighthouse can look healthy while CrUX still needs improvement. Here is how we decide which signal to trust when the two disagree.
The Lighthouse performance score on the ticket was 92. Mobile lab LCP sat under 2.5 seconds. Someone pasted the PageSpeed Insights link into Slack with a green check, and the thread closed before lunch.
Two days later Search Console still showed the URL group as Needs improvement on mobile. Chrome UX Report percentiles had not moved. The client's campaign page felt fine in a warm office on fibre; field users on mid-range phones were still waiting on the hero. Both numbers were honest, and both were answering different questions. That split is the ordinary case of lab green and field amber. Teams that treat it as a tooling bug waste a sprint arguing about which dashboard is right. Teams that treat lab and field as separate jobs prioritise more clearly and close fewer tickets on a Lighthouse performance score alone.
Why Lighthouse lab scores and CrUX field data disagree on the same URL
Lab data from Lighthouse (the engine behind PageSpeed Insights lab results) is a controlled run: fixed device profile, throttled network, repeatable conditions. It is strong for catching regressions you introduced in a deploy, for comparing template A against template B, and for reproducing a slow interaction in DevTools. Field data from the Chrome UX Report is a distribution of real visits: real devices, real networks, real scroll depth, and real interaction paths. Google's lab versus field guidance on web.dev is blunt about the gap: Lighthouse returns one LCP candidate for a given run, while field LCP on the same URL often spans several elements depending on viewport and how far the user scrolled.
Amber field percentiles with a green lab score usually mean the controlled run never hit the conditions that dominate your traffic. A consent banner that only appears for a large share of European visitors, a third-party tag that fires after a marketing campaign starts, or a product gallery that mid-range Androids struggle with can all stay invisible in a single lab profile. The reverse pattern shows up too: lab red because a synthetic throttle is harsh, while CrUX already looks healthy for the visitors who matter. Neither case is a contradiction; it is a mismatch of populations, and treating either number as the only truth usually sends engineering at the wrong work.
Device form factor makes the same disagreement louder. PageSpeed Insights and CrUX already split mobile and desktop; a lab desktop run that looks green does not clear a mobile field fail on the same URL. We covered paired device reporting in two device stories, one URL. Lab versus field sits next to that problem: even on one form factor, a green lab row and an amber CrUX row can coexist for weeks after someone declared the page fixed.
Which PageSpeed signal to trust when lab and field disagree
We use a short decision order in triage, not a debate about which score looks better in a screenshot.
When CrUX or Search Console has usable field data
Search and experience claims should follow CrUX percentiles and Search Console URL-group status, not a single Lighthouse performance score. Lab still tells you what to change next. It does not redefine whether real users are already fine.
When CrUX field samples are missing or thin
New templates, low-traffic locales, and production paths that behave like staging often lack URL-level CrUX samples. PageSpeed Insights may fall back to origin-level field data, which can flatter or hide a single money URL. In those cases we schedule lab runs, store them, and refuse to claim Core Web Vitals are good from a performance score alone. Label those rows lab-only so nobody mistakes them for field proof.
When Lighthouse and CrUX move in different directions
A deploy that adds a script often moves lab first. A traffic mix shift or a third-party change that only hits a segment of visitors often moves field without a matching lab spike on your default profile. When both move, we treat it as confirmation. When only one moves, we write that into the ticket so nobody fixes the green side while ignoring the amber side.
Keep mobile and desktop Core Web Vitals as separate rows
Averaging them into one pass/fail hides the weaker device behind a single result. A lab desktop pass does not clear a mobile CrUX fail on the same URL, and the reverse is also true. For schedules and budgets that keep both form factors honest, see mobile versus desktop Core Web Vitals monitoring on the Watcher blog.
How to run a weekly lab-versus-field PageSpeed reconciliation
On Monday we pull the priority URL list: homepage, primary landing templates, and conversion paths, each with mobile and desktop. For each row we record lab LCP, INP, and CLS from the latest scheduled run, plus CrUX or Search Console status when samples exist. A one-line note captures whether lab and field agree, disagree, or whether field is origin-fallback only.
Disagreements go into three buckets. Lab green / field amber means investigate real-user conditions the lab profile missed: third parties, consent, device skew, or an LCP element that only appears for a large share of visits. Lab amber / field green means keep watching, but do not block a release solely on a harsh lab profile unless the URL is new and has no field history yet. Both amber means pick the metric that fails in field first, then use lab to reproduce and verify the fix.
We do not paste a single PageSpeed Insights screenshot into the client channel as this week's health. Screenshots without stored history become the Tuesday-green, Thursday-panic pattern: a green lab run with nothing saved between checks. Scheduled runs, named baselines, and a short reconciliation note scale better across a roster than ad hoc one-off checks. For when manual PageSpeed Insights is enough and when it is not, the longer comparison stays on the Watcher blog: PageSpeed Insights versus automated monitoring.
How to explain lab green and field amber to clients
Clients hear green score and assume Search is happy. When field data lags or disagrees, the account manager needs one sentence that names both signals. A wording that works in our experience: "Lab tests on our standard mobile profile look healthy after the deploy; real-user Core Web Vitals for this URL group are still in Needs improvement, so we are treating field as the priority and using lab to verify each fix." That sentence does not apologise for the tools. It assigns jobs: field for user and Search status, lab for engineering feedback loops.
If only origin-level field data is available, say so: "We do not yet have URL-level field samples for this landing page; the lab series is our early-warning signal until CrUX fills in." Honesty about sample coverage beats a blended performance score that implies certainty you do not have. The client can then fund the field problem without thinking you contradicted last week's lab screenshot, and engineering keeps a clear label on what is lab-only until URL-level CrUX appears.
Add a lab-versus-field check to this week's monitoring list
Pick five money URLs and open the latest PageSpeed Insights (or monitoring) results with mobile selected. For each URL, write whether lab and field agree, disagree, or whether field is missing or origin-only. Add the same pass for desktop on the two highest-revenue paths. Change one alert or report so a lab-only improvement cannot close a ticket while CrUX on that URL group remains amber. Store the next week's runs against the same URL list so the reconciliation is a habit, not a special project after a client complaint.
Reconcile lab and field before you close the ticket
Treat green lab and amber field as two measurements with different jobs, not a vote to ignore one dashboard. Use the PageSpeed Insights versus automated monitoring guide when you need the workflow split between spot checks and scheduled history, and the mobile versus desktop monitoring guide when the disagreement is also a form-factor split. Reconcile both signals before you treat a Lighthouse performance score as closed.
Originally published on Hashnode.