A Magento store can score 95 in Lighthouse and still fail Core Web Vitals in Search Console, because the two tools measure different things. Lighthouse loads your page once, on one simulated device, from one location. Search Console grades you on what real shoppers experienced over the last 28 days, and Google ranks and reports on the second number, not the first. If you only watch Lighthouse, you are studying for the wrong exam.
We do Magento performance work for a living, and this mismatch is the single most common source of confusion in the first call with a new client. It is also, uncomfortably, a number some agencies lean on in sales decks because it is easy to move. Here is what each number means, why they disagree, and how to fix the one that pays.
What is the difference between lab data and field data?
Lab data is a synthetic test run in a controlled environment; field data is the recorded experience of your actual visitors. Google’s own engineering documentation draws the line plainly: a lab test is one device, on one network, from one location, while field data reflects the full spread of real devices, connections, and behavior across everyone who loads the page. Lighthouse, and the top half of a PageSpeed Insights report, is lab. The Chrome User Experience Report, known as CrUX, is field, gathered from real Chrome users as they browse.
Field data is not one number. It is a distribution. Some shopper on fiber in Manhattan gets your product page in under a second, and someone on a weak cell connection upstate waits six. Both are your store. The lab test is just one more point somewhere inside that spread, which is why it can sit far from what most of your customers feel.
Why does Google grade you at the 75th percentile?
Because Google wants the grade to describe most of your visitors, not your average one. To pass a Core Web Vitals metric, at least 75 percent of page loads have to hit the good threshold, a bar Google chose deliberately and explains in its thresholds documentation. Averages hide the slow tail. The 75th percentile drags it into the light.
This is the detail that breaks the Lighthouse habit. Your simulated run might land near your fastest quartile, while the grade is set by your slowest one. A store whose desktop pages fly and whose mobile checkout crawls can post a beautiful lab score and a failing field grade at the same time, and the Search Console Core Web Vitals report will show you exactly that in the URL groups it flags.
Why the two numbers disagree on a real Magento store
The short answer: your lab test is not shaped like your traffic. Google’s same lab-versus-field analysis walks through the mechanics, and four of them hit Magento stores hardest.
| Cause | What the lab sees | What shoppers see |
|---|---|---|
| Device and network mix | One emulated phone, one throttled connection | Your real split of budget Androids, iPhones, hotel wifi, LTE |
| LCP element | The same hero element every run | Different largest elements by screen size, login state, promos |
| Cache state | A cold, first-visit load | Returning visitors with warm caches and instant back-button restores |
| Interactivity | A proxy metric, since no one clicks | INP measured on real taps on menus, filters, add to cart |
Two of these deserve a Magento-specific word. First, interactivity: Lighthouse cannot measure Interaction to Next Paint in any real sense because nobody interacts with a synthetic load. On a heavy Luma frontend dragging megabytes of JavaScript, the main thread is exactly where shoppers feel the pain, in the pause after they tap a swatch or a filter. That failure mode only shows up in field data, and it is the one we spend the most time hunting in INP work on Hyvä builds.
Second, layout shift: lab CLS stops at page load, but field CLS counts shifts across the whole visit, including the late-loading promo banner that shoves the buy box down while someone scrolls. A store can look stable in the lab and lose its CLS grade to a single third-party script misbehaving below the fold.
How long until a fix shows up in Search Console?
Plan on up to four weeks, because CrUX is a rolling 28-day window. Ship a real improvement today and it enters the field data mixed with 27 days of the old experience, then washes clean as the window rolls forward. The reverse is also true, and it bites teams constantly: a regression you deployed two weeks ago is already baked into your grade even if you fixed it yesterday. This is why we screenshot the field section of PageSpeed Insights at the start of every engagement and re-check on a weekly cadence, rather than declaring victory off a same-day lab run.
That lag cuts one more way worth knowing: it means nobody can honestly sell you an overnight Core Web Vitals turnaround. The work can be fast. The scoreboard is slow by design.
How to measure what Google actually measures
Start every performance conversation from field data, and use lab tools only to diagnose and rehearse. The working setup we give Magento merchants costs nothing:
- Search Console’s Core Web Vitals report for the pass/fail verdict and the URL groups that are failing, mobile and desktop separately.
- The field data section at the top of PageSpeed Insights for per-page CrUX numbers on LCP, INP, and CLS.
- Lighthouse afterward, to reproduce the failure in a controlled setting and test candidate fixes before they ship.
- Your own real user monitoring if traffic is thin, since CrUX needs enough visits per URL group to report at all.
Then fix in the order the field data dictates, not the order the lab audit lists its suggestions. On Magento storefronts the usual culprits behind a failing field grade are slow server response and oversized hero media for LCP, which we broke down in why your Magento store is slow, and JavaScript main-thread weight for INP. Google’s case studies collection ties these field metrics directly to revenue, which is the argument that gets performance work funded.
This is also the honest way to evaluate a frontend rebuild. The reason Hyvä moves Core Web Vitals where Luma cannot, which we covered at length in the piece linked below, is not that it games a lab test. It ships a fraction of the JavaScript, so the median budget-phone shopper, the one setting your 75th percentile, gets a page that responds. Field data is where that shows up, four weeks later, in green.
The question to ask your agency
When a performance report lands on your desk, ask one thing: is this lab or field? If every screenshot is a Lighthouse gauge and nobody mentions CrUX, the 28-day window, or the 75th percentile, you are looking at the easy number. We build and tune Magento frontends on Hyvä at Bemeir, and we put field data in front of clients even when it is slower to move and harder to take credit for, because it is the number Google grades, and the one your shoppers already gave you. Our full working checklist lives in the resources below, and it starts where this article ends: open Search Console before you open Lighthouse.
Related Resources
- Will Hyvä fix your Core Web Vitals? What Magento 2 teams should expect
- Core Web Vitals checklist for Magento teams chasing a passing score
- Why your Magento store is slow: the usual suspects behind bad LCP
- INP optimization on Hyvä: hunting long tasks and hydration cost
- CLS on Hyvä: layout shift killers on Adobe Commerce
- Hyvä vs Luma: a practitioner’s comparison of Magento 2 frontend performance
