Why PageSpeed Insights, Search Console, Lighthouse, and GTmetrix disagree.
These tools answer different questions. Some report delayed real Chrome-user field data. Others run immediate lab diagnostics. The fix starts by labeling the source before debating the score.
No signup needed. Takes about 30 seconds.
Decision preview
Search Console says poor. Lighthouse says good. Treat Search Console as field evidence, then use the lab run to inspect the likely cause.
Source: CrUX field data
Diagnostic: Lighthouse lab data
Next check: same URL, same device, same source label
Source labels
The same page can be good, poor, and unmeasured at the same time.
That does not mean one tool is broken. It usually means the report is using a different source, window, device profile, or URL group.
CrUX field data
PageSpeed Insights, Search Console
Real Chrome-user experience data when the page or origin has enough public samples.
Trust it first for user impact, but remember it is delayed.
Lighthouse lab data
PageSpeed Insights, DevTools, CLI, GTmetrix-style tests
A point-in-time diagnostic run in a controlled device, network, and browser setup.
Use it to debug a likely cause and verify same-day changes.
Search Console URL group
Search Console Core Web Vitals report
A site-level grouping of similar URLs with the same metric and device issue.
Use it to prioritize groups, not to prove one exact URL was fixed today.
Synthetic report
GTmetrix and other lab tools
Controlled testing that can add waterfall, filmstrip, location, and monitoring context.
Useful debugging evidence, but compare settings before arguing about scores.
Common contradictions
Start with the question each tool is answering.
Field data answers what a public Chrome sample experienced. Lighthouse and synthetic tools answer what happened in a controlled test. Search Console helps prioritize groups of affected pages.
Search Console fails, Lighthouse passes
Field data is showing a real-user problem.
Inspect the failing metric and affected URL group, then use Lighthouse to find the most likely cause.
Lighthouse fails, Search Console passes
The lab run found a reproducible risk.
Fix cheap, obvious bottlenecks, but do not overrule passing field data from one noisy lab run.
GTmetrix looks good, PSI field data fails
You may be comparing lab evidence with CrUX field evidence.
Check source labels first, then rerun a same-device lab test after each fix.
No field data is available
The page may not have enough public Chrome samples.
Use a consistent lab baseline now and keep monitoring until CrUX data appears.
Use nimo for the handoff
Keep the sources visible until the fix is verified.
nimo turns mixed evidence into a narrower decision: one likely cause, one owner, one first safe fix, and one rerun instruction.
Verification sequence
Run a baseline lab check before the change.
Ship the smallest safe fix for the failing metric.
Rerun the same lab check after deploy.
Watch CrUX field data before calling the field issue closed.
Sources checked
Claims stay tied to official source pages.
Checked on May 20, 2026. Recheck the official docs before adding new tool capability, quota, ranking, or measurement-window claims.
FAQ
Quick answers for conflicting reports.
Which source should I trust first?
Use CrUX field data first when you need user-impact evidence. Use Lighthouse or GTmetrix-style lab data when you need to debug the cause or rerun right after a deploy.
Can a lab test prove a field-data fix worked?
It can prove the tested URL changed in that lab setup. It cannot prove the delayed CrUX field window has recovered yet.
Where does nimo fit?
nimo keeps the source labels visible, explains the contradiction, and turns the evidence into one owner, one first safe fix, and one rerun check.