Shopify speed testing: which tools to trust

Run the same Shopify store through five speed tools and you'll get five different numbers. That's not a fault in the tools — they measure different things. Knowing which to act on saves a lot of wasted work.

The one that counts: field data

Search Console → Core Web Vitals. Real users, real devices, real networks, grouped by URL pattern, mobile and desktop separately.

This is what Google actually ranks on. If it says your product pages are fine, they're fine — regardless of what a Lighthouse score says.

Two properties to remember: it's a 28-day rolling window, so a fix takes weeks to show; and it needs enough traffic to report at all, so very small stores may see nothing.

Start every performance conversation here.

PageSpeed Insights

Gives you both: field data at the top (real users, the number that matters) and lab data below (a simulated run on Google's hardware).

The lab score is the big number people fixate on. It's useful for iteration because it's repeatable, and it produces a specific list of opportunities. It is not what you're ranked on, and chasing 100 is not a good use of anyone's time.

Test on mobile, and test your biggest collection page and your most-visited product page — not the homepage.

Lighthouse in Chrome DevTools

The same engine as PageSpeed Insights' lab section, run locally. Faster to iterate with, and it uses your machine and connection, so throttle it: mobile device, slow 4G, 4× CPU slowdown. Without throttling it flatters you enormously.

Useful for before-and-after on a specific change.

DevTools directly

Where you actually diagnose things, once you know something is wrong:

• Network tab — what loads, how big, how long. Sort by size. Check TTFB on the document request for server response time.
• Performance tab — record a load, find the long tasks blocking the main thread. This is how you diagnose INP.
• Coverage tab — how much of each file is actually used. Revealing for app scripts.

WebPageTest

Slower and more thorough. Real devices in real locations, filmstrip view, and a waterfall that makes render-blocking obvious.

Worth using when you need to see exactly what happens in the first three seconds, or to test from a country your customers are in and you aren't.

Why the numbers disagree

Common and confusing:

• Field data lags lab data by weeks.
• Lab data is a single run on specific hardware; field data is thousands of runs on everything.
• Your connection is not your customers'. Testing on office wifi on a new laptop tells you nothing.
• Apps behave differently for logged-in staff.
• A/B tests and personalisation change what's on the page.

When lab and field disagree, field wins.

A workflow that works

1. Search Console — which templates are failing, and on which vital.
2. PageSpeed Insights on a representative URL — confirm, and get the opportunity list.
3. DevTools — diagnose the specific cause.
4. Fix.
5. Lighthouse locally — confirm the change did what you expected.
6. Wait, then check Search Console again — confirm it reached real users.

Step six is the one people skip, and it's the only one that proves anything.

What not to do

• Chasing a lab score of 100. Beyond "good", further gains are marginal and expensive.
• Testing only the homepage. It's rarely the page that matters.
• Testing on desktop. Your customers are on phones.
• Trusting an app's own dashboard about how fast it makes you.
• Measuring once. Speed regresses every time someone installs something — which is why a performance budget is worth having.

Search Console tells you whether you have a problem. DevTools tells you what it is. Everything else is a second opinion.