Usually both. They measured different things. Don't average the scores or pick the one you like: check whether they measured the same metric, source, page, device, time window, and test conditions.
Neither result automatically invalidates the other. First check whether both reports use the same metric, field or lab source, exact URL or origin-level aggregate (scheme, host, and port), mobile or desktop profile, reporting window, and test conditions.
Use eligible Chrome field evidence to understand observed experience over time. Use repeatable lab tests to try to reproduce the symptom, inspect likely causes, and recheck immediately after a change.
If public field data is missing, the result is unknown—not good. Keep a consistent lab baseline, and use first-party real-user monitoring (RUM)—measurements collected from visits to your own site—when the business needs owned visitor evidence.
What each report measured
PageSpeed Insights and GTmetrix can each show both kinds. Name the panel before you compare the number.
What real Chrome visits experienced
p75 is not an average. It is the 75th percentile: at least 75% of included metric experiences were at or below that value—not 75% of unique visitors.
CrUX updates daily over a trailing 28-day period with processing delay. After a change, new visits gradually replace older ones. There is no instant, clean post-change window.
Source: Chrome CrUX APIOne controlled test, right now
Before you trust either result
Most apparent conflicts compare unlike evidence. If any of these differ, you are not looking at a real contradiction yet.
An individual LCP, CLS, or INP metric—not a Lighthouse score versus a Core Web Vitals assessment.
Field compared with field, or lab compared with a comparable lab run.
Exact URL, origin-level aggregate (scheme, host, and port), or Search Console group of URLs with similar user experience.
Mobile and desktop remain separate.
A trailing field window is not the same moment as a lab test run now.
URL, tool/version, location, device/viewport, network/CPU profile, cache and consent state, and content variant.
Name the panel
“PageSpeed,” “Lighthouse,” and “GTmetrix” are not single data sources.
Field — Chrome UX Report (CrUX)
URL-level data when available; PSI may show origin-level data instead. Confirm the displayed scope. Mobile or desktop. Trailing 28-day collection period at p75.
Use it to: Judge observed experience for the eligible public Chrome sample over time.
Can't prove: Every visitor's experience, same-day behavior, or the exact page when PSI is showing origin data.
Lab — Lighthouse
One simulated run of the tested URL on the selected mobile or desktop profile.
Use it to: Try to reproduce the symptom and inspect likely causes immediately.
Can't prove: Historical real-user experience, a stable change from one run, or later field recovery.
Field — CrUX
URLs grouped by similar user experience (or origin groups), with device-specific status and metric issues. Last 28 days at p75.
Use it to: Prioritize affected site sections and inspect representative URLs.
Can't prove: That every exact URL in the group has the same result or that today's change is processed.
Lab — controlled browser run
The exact tested URL in one run; conditions vary by runner, hardware, network, and page state.
Use it to: Debug repeatable loading and main-thread work under known conditions.
Can't prove: A Core Web Vitals field pass, direct INP, or causality from a single score change.
Lab — Lighthouse-powered real-browser test
One tested URL with configurable location, device, connection, and analysis options.
Use it to: Inspect a waterfall, video, Lighthouse diagnostics, and repeatable configured tests.
Can't prove: That its conditions match PSI or that a good lab grade overrules poor field evidence.
Field — CrUX displayed by GTmetrix
Public CrUX evidence when available; keep its page/origin and device labels attached.
Use it to: Review eligible Chrome field experience without confusing it with the GTmetrix lab grade.
Can't prove: First-party RUM, every visitor's experience, or current behavior outside the CrUX window.
Decision matrix
Each answer says what the result can support and where the evidence stops. It does not promise a pass, recrawl date, ranking, or traffic change.
You see
What it means
A Search Console URL or origin group had poor CrUX field evidence. A good Lighthouse run did not show the same load-time symptom; for INP, Lighthouse does not provide a direct comparison.
Your one next step
Open the failing device, metric, and URL group. Test one representative affected URL repeatedly with the same lab setup. For INP, inspect long tasks and TBT only as clues.
Don't conclude
Do not assume every grouped URL currently fails, or call the field issue fixed from one good run.
You see
What it means
One lab run found a problem under its conditions; the available grouped field evidence is not showing the same status.
Your one next step
Repeat the exact URL with the same tool and settings. If the same bottleneck repeats, choose the smallest metric-specific fix.
Don't conclude
Do not infer that most visitors have poor Core Web Vitals from one lab run.
You see
What it means
The reports may use different sources or conditions. A GTmetrix lab grade and its CrUX panel are different evidence.
Your one next step
Name the panel first. Compare field with field, or rerun lab tests with matching URL, device, location, network, and timing.
Don't conclude
Do not average unlike scores or choose the more favorable result.
You see
What it means
Google did not return enough public CrUX evidence for the URL or origin. This is unknown, not good.
Your one next step
Check whether PSI is showing origin fallback. Save a consistent lab baseline and use first-party RUM if you need owned visitor evidence now.
Don't conclude
Do not promise that waiting will produce URL-level CrUX data.
You see
What it means
Lab evidence can react now; public field evidence is delayed and covers a trailing window.
Your one next step
Preselect equal before/after run counts and a summary such as the median. Keep all run values, then review a later compatible field window.
Don't conclude
Do not claim field recovery, ranking or conversion impact, or causality from the immediate rerun.
Illustrative example — not measured results
Lighthouse
Performance score
Search Console
4.2 s
Mobile group LCP
Illustrative numbers, not a Nimo audit: one page-load score is green while the Search Console group has poor historical LCP. Those are not equivalent outputs.
Limit: An individual URL may differ from the group aggregate. One fast run does not clear the group issue, and the Lighthouse score does not identify the field cause.
Illustrative example — not measured results
PSI · this URL
No data
URL-level field
PSI · origin
2.1 s
Origin-level LCP
Illustrative numbers, not a Nimo audit: PSI shows good origin-level LCP context while the tested product page has no URL-level field evidence.
Limit: A good origin metric is not a pass for the product page or all three Core Web Vitals. Do not remove merchandising apps without an owner and business-value review.
Report A / panel: Report A URL: Report A metric / value / units / status: Report B / panel: Report B URL: Report B metric / value / units / status: Metric (not overall score): Source type (field or lab): Scope (URL, origin, or Search Console group): Device / viewport: Observation date / collection period: Lab runner/version, location, network/CPU profile: Cache, consent state, and content variant: Preselected before/after run counts / all values / summary (for example, median): One next check / owner: What this evidence cannot prove:
Category errors
Each pair looks comparable. None of them are.
Do not compare a Lighthouse 0–100 performance score with a Core Web Vitals pass/fail assessment. They are different outputs.
Do not compare TBT with field INP as though they are the same metric. Use TBT and long tasks only to investigate responsiveness work.
Do not relabel origin-level CrUX as evidence for one exact URL.
Do not treat a Search Console example URL as proof that every URL in its group has the same measurement.
Do not compare mobile and desktop, or lab runs with different locations, network/CPU profiles, viewports, tool versions, cache/consent states, or content variants.
A page-load lab run can miss interactions and layout shifts later in a visit. A clean load-time CLS is not proof of full-session stability.
Do not compare one immediate lab run with a trailing field-data window and call the difference a contradiction.
After you find the failing metric
LCP
Largest Contentful Paint
For LCP, identify the largest element and whether server response, discovery delay, resource loading, or render delay dominates before choosing a fix.
LCP guideCLS
Cumulative Layout Shift
For CLS, identify the elements that moved and the late content, font, image, embed, or UI state that changed their reserved space.
CLS guideINP
Interaction to Next Paint
For INP, use field INP for the user-experience verdict. Use long tasks, interaction traces, and TBT only as lab clues to the main-thread work worth investigating.
INP guideFor any metric, keep the exact URL, mobile or desktop profile, source scope, and observation date attached to the number.
Verify without fooling yourself
Record the failing source, scope, device, metric, and observation window before changing anything.
Before testing, choose equal before/after run counts (for example, five each) and a summary such as the median. Keep all run values. Match URL, runner/version, location, viewport/device, network/CPU profile, cache/consent state, and content variant.
Choose one bounded fix tied to the failing metric and name the owner or handoff.
Verify that the intended change is live, then repeat several matching lab runs. Record the run count and a summary method such as the median; do not pick the best run.
Review a later compatible CrUX or Search Console window before describing the field status; report movement without claiming causation.
Where nimo fits
Check a public page
Nimo labels available CrUX field evidence separately from Lighthouse lab diagnostics returned through PageSpeed Insights.
Public URL. No signup.
Keep going
The fine print
Sources reviewed September 30, 2026
FAQ
Search Console groups URLs it considers to have a similar user experience, then reports device-specific CrUX field status and metric issues over time. Lighthouse is one controlled test of one URL. Use the group result to prioritize the real-user issue, then use repeatable lab runs to investigate a representative page.
First identify the panel. Both tools can show CrUX field evidence, while their Lighthouse-powered lab tests can use different locations, devices, networks, and settings. Compare matching source types and conditions before deciding that the results conflict.
No. The Lighthouse performance score is a weighted lab score, not the Core Web Vitals field assessment. A good lab run can coexist with poor or unavailable field data.
Matching repeated lab runs can show a directional change under those test conditions. They do not prove that the change caused the movement or that the later CrUX field window has recovered.
Treat the field result as unknown. Check whether origin-level data is available, keep a consistent lab baseline, and use first-party RUM if you need evidence from your own visitors now. Do not assume URL-level CrUX will appear.
Ready to label your own evidence?
Run a public-page audit, then check that URL-level, origin-level, lab, and unavailable evidence remain clearly labeled.
Run the free auditNeed the machine-readable version? Use /field-vs-lab-core-web-vitals.md.