Magento · 17 August 2026 · 9 min read
Why your store scores well on PageSpeed and is slow for customers
The PageSpeed score is a simulation on a phone that doesn't exist, on a network that belongs to nobody. The data that matters is different, and it's free.
The situation is common and confusing: you run PageSpeed, get a score in the nineties, and feel fine. Then a customer tells you the store is sluggish, and you have nothing to say back.
You're both right. You're measuring different things.
Two kinds of data, easily confused
| Lab data | Field data | |
|---|---|---|
| What it is | A simulation, on a device and network defined by the tool | Real measurements, from your actual visitors |
| Where it comes from | Lighthouse, the “Analysis” tab in PageSpeed | CrUX, the Core Web Vitals report in Search Console |
| How long it takes | Immediate result | A rolling 28-day window |
| What it's good for | Debugging: it shows you what is slowing the page down | Truth: it shows you what your customers experience |
| What Google uses for ranking | None of it | This |
The score of 90 comes from the first column. The customer's complaint comes from the second. That's why they don't contradict each other.
Why they differ so much
The simulated phone is better than your customers'
The simulation assumes a mid-range device. A good share of ecommerce traffic comes from older, slower phones, where JavaScript executes several times more slowly.
It tests one page, usually the homepage
Almost everybody runs the test on the homepage, which is the most optimised page there is. Customers land on product and category pages, with filters, with many images, with extensions that only load there.
The test has no cart and isn't logged in
In Magento the difference is enormous. A visitor with items in the cart gets personalised content, which can't be served from cache. The test never sees that situation.
The cache is warm for the test and cold for the customer
When you run the test a second time, the page is already cached. The customer who arrives first thing in the morning, after invalidation, gets it cold.
The marketing script added last Tuesday
The most frequent culprit. Tracking tags, chat, heatmaps, A/B tests — all added through a tag manager, without passing anyone technical. They never come up in performance discussions because nobody thinks of them as “code”.
What to look at, in order
- The Core Web Vitals report in Search Console. Free, on real data, grouped by page type. This is where you find the truth.
- Separate mobile from desktop. The problem is almost always mobile only, and the average hides it.
- Look by page type, not by site. The homepage can be green while the product page is red.
- Check INP, not just LCP. LCP measures how long until you see something. INP measures how long until it responds to a tap — and that also degrades from JavaScript.
- Only then run Lighthouse, to find out why. On the page that performs badly in the field, not on the homepage.
What fixes this structurally
If your field data is red on mobile and the store runs on the stock theme, the cause is almost certainly the frontend stack. A megabyte and a half of JavaScript isn't optimised, it's removed — that's what Hyvä does.
If you're already on Hyvä and it's still slow, the cause is elsewhere. We've written separately about what's going on in that case.