# PageSpeed Insights says failed. GTmetrix says great. Which result should you trust?

A source-backed decision guide for conflicting PageSpeed Insights, Search Console, Lighthouse, and GTmetrix results.

Canonical URL: https://heynimo.com/field-vs-lab-core-web-vitals
Markdown URL: https://heynimo.com/field-vs-lab-core-web-vitals.md
Sources checked: September 30, 2026

## AI summary

Neither result automatically invalidates the other. First align the metric, field or lab source, URL scope, device, reporting window, and lab conditions. Use eligible Chrome field evidence for observed experience over time and repeatable lab evidence to diagnose and recheck now.

## Direct answer

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.

## Before you compare two reports

- Same result: an individual LCP, CLS, or INP metric—not a Lighthouse score versus a Core Web Vitals assessment.
- Same source type: field compared with field, or lab compared with a comparable lab run.
- Same scope: exact URL, origin-level aggregate (scheme, host, and port), or Search Console group of URLs with similar user experience.
- Same device class: mobile and desktop remain separate.
- Compatible time: a trailing field window is not the same moment as a lab test run now.
- Same lab conditions: URL, tool/version, location, device/viewport, network/CPU profile, cache and consent state, and content variant.

## What each report measured

### PageSpeed Insights field panel

- Source type: Field — Chrome UX Report (CrUX)
- Scope and window: 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.
- Best use: Judge observed experience for the eligible public Chrome sample over time.
- Cannot prove: Every visitor's experience, same-day behavior, or the exact page when PSI is showing origin data.
- Official source: [Google PSI documentation](https://developers.google.com/speed/docs/insights/v5/about?hl=en)

### PageSpeed Insights lab panel

- Source type: Lab — Lighthouse
- Scope and window: One simulated run of the tested URL on the selected mobile or desktop profile.
- Best use: Try to reproduce the symptom and inspect likely causes immediately.
- Cannot prove: Historical real-user experience, a stable change from one run, or later field recovery.
- Official source: [Google PSI documentation](https://developers.google.com/speed/docs/insights/v5/about?hl=en)

### Search Console Core Web Vitals

- Source type: Field — CrUX
- Scope and window: URLs grouped by similar user experience (or origin groups), with device-specific status and metric issues. Last 28 days at p75.
- Best use: Prioritize affected site sections and inspect representative URLs.
- Cannot prove: That every exact URL in the group has the same result or that today's change is processed.
- Official source: [Search Console documentation](https://support.google.com/webmasters/answer/9205520?hl=en)

### Lighthouse in DevTools or CLI

- Source type: Lab — controlled browser run
- Scope and window: The exact tested URL in one run; conditions vary by runner, hardware, network, and page state.
- Best use: Debug repeatable loading and main-thread work under known conditions.
- Cannot prove: A Core Web Vitals field pass, direct INP, or causality from a single score change.
- Official source: [Lighthouse variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md)

### GTmetrix performance test

- Source type: Lab — Lighthouse-powered real-browser test
- Scope and window: One tested URL with configurable location, device, connection, and analysis options.
- Best use: Inspect a waterfall, video, Lighthouse diagnostics, and repeatable configured tests.
- Cannot prove: That its conditions match PSI or that a good lab grade overrules poor field evidence.
- Official source: [GTmetrix features (vendor claim)](https://gtmetrix.com/features/)

### GTmetrix CrUX panel

- Source type: Field — CrUX displayed by GTmetrix
- Scope and window: Public CrUX evidence when available; keep its page/origin and device labels attached.
- Best use: Review eligible Chrome field experience without confusing it with the GTmetrix lab grade.
- Cannot prove: First-party RUM, every visitor's experience, or current behavior outside the CrUX window.
- Official source: [GTmetrix features (vendor claim)](https://gtmetrix.com/features/)

## Common conflicts

### Search Console is poor; Lighthouse is good

- 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.
- 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.
- Do not conclude: Do not assume every grouped URL currently fails, or call the field issue fixed from one good run.

### Lighthouse is poor; Search Console is good

- What it means: One lab run found a problem under its conditions; the available grouped field evidence is not showing the same status.
- Next step: Repeat the exact URL with the same tool and settings. If the same bottleneck repeats, choose the smallest metric-specific fix.
- Do not conclude: Do not infer that most visitors have poor Core Web Vitals from one lab run.

### GTmetrix is good; PSI field data is poor

- What it means: The reports may use different sources or conditions. A GTmetrix lab grade and its CrUX panel are different evidence.
- Next step: Name the panel first. Compare field with field, or rerun lab tests with matching URL, device, location, network, and timing.
- Do not conclude: Do not average unlike scores or choose the more favorable result.

### PageSpeed Insights has no field data

- What it means: Google did not return enough public CrUX evidence for the URL or origin. This is unknown, not good.
- 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.
- Do not conclude: Do not promise that waiting will produce URL-level CrUX data.

### A change just went live

- What it means: Lab evidence can react now; public field evidence is delayed and covers a trailing window.
- 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.
- Do not conclude: Do not claim field recovery, ranking or conversion impact, or causality from the immediate rerun.

## Verification sequence

1. Record the failing source, scope, device, metric, and observation window before changing anything.
2. 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.
3. Choose one bounded fix tied to the failing metric and name the owner or handoff.
4. 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.
5. Review a later compatible CrUX or Search Console window before describing the field status; report movement without claiming causation.

## Worked examples (illustrative, not measured results)

### WordPress: Lighthouse 96, mobile group LCP 4.2 seconds

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.

Next step: Open the mobile LCP issue and inspect its group scope. Test a representative URL with repeated matching mobile runs; identify the LCP element and load-delay breakdown before changing the image, cache, or theme.

Boundary: 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.

### Shopify: URL field data missing, origin LCP 2.1 seconds

Illustrative numbers, not a Nimo audit: PSI shows good origin-level LCP context while the tested product page has no URL-level field evidence.

Next step: Label 2.1 seconds as origin context, not product-page LCP. Use repeated lab runs on that product URL and inspect hero media, theme work, and app scripts. Use first-party RUM if the exact page needs visitor evidence now.

Boundary: 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.

## Copyable report comparison worksheet

```text
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:
```

## This guide is not for

- Session-level or same-day evidence from your own visitors; use first-party RUM for that job.
- A replacement for deep waterfall, trace, backend, database, or authenticated-flow investigation.
- Automatic WordPress plugin, theme, Shopify theme, or app changes. Nimo does not rewrite that code for you.
- An instant field verdict after a change. Public CrUX evidence is delayed and can remain unavailable.

## Frequently asked questions

### Why can Search Console fail when Lighthouse passes?

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.

### Why can GTmetrix and PageSpeed Insights disagree?

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.

### Does a good Lighthouse score mean the page passes Core Web Vitals?

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.

### Can a lab rerun prove a Core Web Vitals fix worked?

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.

### What should I do when PageSpeed Insights has no field data?

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.

## Key caveats

- CrUX is aggregated public Chrome field data for eligible visits, not every visitor and not first-party RUM.
- PageSpeed Insights may show URL-level CrUX, fall back to origin-level CrUX, or show no field data. Preserve that scope.
- Search Console groups URLs it considers to have a similar user experience, then reports device-specific status and metric issues for each group. A group result does not prove every exact URL has the same status.
- The Lighthouse performance score is not a Core Web Vital or the Core Web Vitals pass/fail assessment.
- Lighthouse does not provide a direct lab INP equivalent. TBT and long tasks are diagnostic clues, not replacement INP measurements.
- GTmetrix can show both Lighthouse-powered test evidence and CrUX field evidence. Name the panel before comparing it with another tool.
- CrUX updates daily over a trailing 28-day period with processing delay. New visits gradually replace older ones; it is not an instant post-change cohort.
- p75 means the 75th percentile, not an average: at least 75% of included metric experiences were at or below the reported value, not 75% of unique people.
- Search Console can use an origin-level group when a narrower group lacks data; check the group scope before assigning a problem to a template.
- A matching lab rerun can show a directional change under those conditions; it cannot prove later field recovery or causality by itself.
- Missing public field data is unknown, not a pass, and URL-level CrUX may never become available.

## Do not compare these numbers directly

- 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.

## Metric-specific next checks

- For LCP, identify the largest element and whether server response, discovery delay, resource loading, or render delay dominates before choosing a fix.
- For CLS, identify the elements that moved and the late content, font, image, embed, or UI state that changed their reserved space.
- 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.
- For any metric, keep the exact URL, mobile or desktop profile, source scope, and observation date attached to the number.

## Where nimo fits

- Nimo's public audit can combine available CrUX field evidence with PageSpeed Insights diagnostics, preserve unavailable values, and prioritize a first fix.
- A matching rerun can compare the same page after a change. Signed-in plans can store history and run scheduled audits.
- Nimo does not provide first-party RUM, automatically rewrite WordPress or Shopify code, or replace the deep waterfall and trace workflows in specialist tools.
- Supported Cloudflare changes remain limited and require explicit approval; code changes remain recommendations or handoffs.

## Sources

- [Google: About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about?hl=en)
- [Google: Search Console Core Web Vitals report](https://support.google.com/webmasters/answer/9205520?hl=en)
- [Chrome: CrUX methodology](https://developer.chrome.com/docs/crux/methodology?hl=en)
- [Chrome: CrUX API scopes and collection period](https://developer.chrome.com/docs/crux/api?hl=en)
- [Chrome: Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring?hl=en)
- [Chrome: Lighthouse variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md)
- [web.dev: Why lab and field data can differ](https://web.dev/articles/lab-and-field-data-differences)
- [GTmetrix: Features and measurement sources](https://gtmetrix.com/features/)

## Related nimo pages

- [Run a free field-and-lab audit](https://heynimo.com/free-core-web-vitals-audit)
- [Compare Nimo with PageSpeed Insights](https://heynimo.com/compare/pagespeed-insights)
- [Compare Nimo with GTmetrix](https://heynimo.com/compare/gtmetrix)
- [WordPress Core Web Vitals first checks](https://heynimo.com/wordpress-core-web-vitals-first-fixes)
- [Shopify Core Web Vitals first checks](https://heynimo.com/shopify-core-web-vitals-first-fixes)
- [Core Web Vitals glossary](https://heynimo.com/web-performance-glossary/core-web-vitals)
- [Largest Contentful Paint (LCP)](https://heynimo.com/web-performance-glossary/lcp)
- [Interaction to Next Paint (INP)](https://heynimo.com/web-performance-glossary/inp)
- [Cumulative Layout Shift (CLS)](https://heynimo.com/web-performance-glossary/cls)
- [Audit data and reruns](https://heynimo.com/docs/audits)