PageSpeed Insights vs Lighthouse vs CrUX: Which Performance Data Actually Matters for Ecommerce

You run PageSpeed Insights on your store and get a score of 43. You open Lighthouse in Chrome DevTools and get 71. Then you check the Chrome UX Report and see your LCP in the field is "Good." Three tests, three different answers. Which one is right?

All three are — they're measuring different things. Understanding the difference isn't academic; it determines whether you're chasing the right performance metric or optimizing for a number that doesn't affect your rankings or conversions.

What Each Tool Actually Measures

Google Lighthouse

Lighthouse is a lab test. It loads your page in a controlled, simulated environment — a throttled mobile connection (Moto G4 equivalent CPU, 4x CPU slowdown, simulated 4G), no cached assets, no cookies, no extensions. It generates a performance score from 0-100 based on a weighted combination of five metrics:

• First Contentful Paint (FCP) — 10%
• Speed Index — 10%
• Largest Contentful Paint (LCP) — 25%
• Total Blocking Time (TBT) — 30%
• Cumulative Layout Shift (CLS) — 25%

Lighthouse is deterministic, reproducible, and runs consistently regardless of your traffic volume. You can run it on any page — even pages with no traffic. Its weakness: the synthetic environment doesn't reflect real visitor conditions.

Chrome UX Report (CrUX)

CrUX is real-user data. Google collects anonymized performance data from Chrome users who have opted into sharing usage statistics. This data reflects actual visitor experiences on real devices, real networks, real browser states — cached assets, cookies, extensions, slow Android phones on 3G in rural areas.

CrUX reports the three Core Web Vitals that Google uses as ranking signals:

• Largest Contentful Paint (LCP)
• Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)

CrUX has two significant constraints: it only covers URLs with sufficient traffic (low-traffic pages have no CrUX data), and data is aggregated over a 28-day rolling window, so changes take weeks to appear.

PageSpeed Insights

PageSpeed Insights (PSI) combines both. It runs a Lighthouse lab test on your page and, if CrUX data exists for that URL or its origin, it surfaces the real-user field data alongside the lab results. The score you see in PSI is the Lighthouse lab score — not the CrUX field data.

This is the most common source of confusion. The "PageSpeed score" that everyone fixates on is a synthetic lab number. The actual Google ranking signal comes from the CrUX field data shown separately on the same page.

Which Data Drives Google Rankings?

CrUX field data. Full stop.

Google's Core Web Vitals ranking signal uses real-user data from CrUX — not Lighthouse scores. A Lighthouse score of 40 with excellent CrUX field data will rank better than a Lighthouse score of 95 with poor CrUX field data. The lab score is a diagnostic tool; the field data is what Google uses.

If your CrUX data shows "Good" ratings for LCP, INP, and CLS, your Core Web Vitals are fine from a rankings perspective — regardless of your Lighthouse score.

Why They Disagree So Often

Device distribution

Lighthouse tests on a simulated mid-range Android phone. Your actual visitors might be 70% desktop (which is significantly faster). CrUX aggregates data across your actual device mix, so if most of your visitors are on fast desktop browsers, your field data will look better than your lab data.

Cache state

Lighthouse always runs cold (no cached assets). Real visitors returning to your store have images, fonts, and scripts cached. A heavy homepage might be slow on first visit but fast on subsequent visits — CrUX captures both, Lighthouse only captures the cold-start cold.

Network conditions

Lighthouse simulates a 4G connection with specific throttling parameters. Real visitors have a distribution of connection speeds — fiber, LTE, 3G, congested airport WiFi. CrUX captures this real distribution.

JavaScript execution

Lighthouse measures TBT (Total Blocking Time) as a proxy for INP. But TBT and INP don't correlate perfectly — a page can have high TBT in the lab but good INP in the field if interactions happen when the main thread is idle. Lighthouse is more pessimistic about JavaScript blocking than real users experience.

The Right Way to Use Each Tool

Use CrUX (via PageSpeed Insights or Search Console) to:

• Understand your actual Core Web Vitals ranking status
• Identify which pages are hurting your rankings (Search Console's Core Web Vitals report)
• Measure real performance improvements after optimization (with the caveat that changes take 28 days to appear)
• Benchmark against what your actual visitors experience

Use Lighthouse to:

• Diagnose performance issues on any page (including low-traffic pages with no CrUX data)
• Get specific, actionable recommendations (image optimization, render-blocking resources, unused JavaScript)
• Test performance impact of changes before deploying to production
• Establish a reproducible baseline in your CI/CD pipeline
• Audit new page templates before launch

Use WebPageTest alongside both to:

• Get waterfall charts showing exactly how your page loads resource by resource
• Test from real devices on real connections (not simulated)
• Measure metrics that Lighthouse and PSI don't surface (TTFB by CDN node, connection establishment time)

The Lighthouse Score Trap

Many ecommerce teams spend enormous effort optimizing their Lighthouse score — deferring non-critical JavaScript, removing unused CSS, compressing images — without meaningfully improving their CrUX field data. This is the Lighthouse score trap.

Lighthouse optimizations matter, but only insofar as they improve real user experience. Common scenarios where they diverge:

• Chat widgets and marketing pixels — These hurt Lighthouse TBT significantly but may not affect INP if visitors rarely interact during the JavaScript execution window. Removing them would genuinely improve lab scores but may have no CrUX impact if real users interact only after page load is complete.
• Above-the-fold images — Lighthouse aggressively penalizes large LCP images loaded without fetchpriority="high". Real visitors on high-speed connections may not notice the difference, so the CrUX LCP might already be Good.
• Server-side rendering vs. client-side rendering — SSR dramatically improves Lighthouse scores (especially FCP), but if your real visitors are mostly returning customers with cached assets, the CrUX delta is smaller.

For Ecommerce: Prioritize in This Order

1. Check your CrUX status first — If all three Core Web Vitals are "Good" in Search Console, you don't have a rankings problem. Don't chase a Lighthouse score if your real users are having a good experience.
2. Use CrUX to find the problematic pages — Search Console's Core Web Vitals report groups pages by template type. A pattern of "Poor" LCP on product pages but "Good" on the homepage tells you where to focus.
3. Use Lighthouse to diagnose — Once you know which page templates need work, Lighthouse gives you the specific issues to fix.
4. Validate improvements with CrUX after 28 days — Don't declare victory based on a Lighthouse score improvement. Wait for CrUX to update and verify the field data moved.

What This Means for Store Health Monitoring

Automated store health monitoring catches performance regressions before they compound. A deploy that introduces a render-blocking script, a theme update that adds 500KB of CSS, or a new product image that's 3MB instead of 200KB — these show up immediately in a health scan, before they've had time to hurt your CrUX field data over 28 days.

StoreVitals monitors your store's performance health automatically, flagging render-blocking resources, oversized images, and page weight issues that Lighthouse would flag — so you can catch regressions before they become CrUX problems that take a month to show up in rankings data.