Somebody runs PageSpeed Insights on their store, sees a number in a coloured circle, and either panics or relaxes. Both reactions are based on the one part of the report that cannot tell you what to do.
I am not arguing that speed does not matter. It matters. I am arguing that the headline score is a compressed summary of six measurements weighted against a benchmark, and compressing them back into a single digit throws away the only part you can act on.
On a store I worked on, the score after a significant round of image work was 65 on mobile. That number is useless on its own. The line underneath it, 522 KB of unused JavaScript, is a decision.
Largest Contentful Paint. How long until the biggest visible thing appears. This is the closest single number to what a customer experiences as slow. On that store it was 11.4 seconds, which is the real finding.
Reduce unused JavaScript. This is usually your apps. Every app that adds a widget adds a script, and most load on every page whether or not that page uses them.
Properly size images. This is your uploads and your theme. It tells you how many kilobytes you would save by serving images at the size they are displayed.
PageSpeed Insights shows two kinds of data. Lab data is a simulated load on a simulated slow device, run fresh each time. Field data is real measurements from real Chrome users over the past 28 days, if your store has enough traffic to qualify.
They disagree constantly, and the field data is the one that matters, because it is what your customers actually experienced. Lab data is for diagnosing, field data is for judging.
This is also why the score jumps around when you run it repeatedly. The simulation has variance. Chasing a three point movement is chasing noise.
Change one thing at a time. If you compress images, remove two apps and adjust the theme in the same afternoon, you will have a faster store and no idea which change bought it. That matters, because next time you need to know where to spend the effort.
Record the before. Screenshot the report, including the diagnostics, not just the score. Almost nobody does this, and it is why so many speed claims cannot be checked.
Test the page that matters. Most people test their homepage. Most of your traffic from search and ads lands on product pages, which usually carry more scripts.
Test on a real phone on real mobile data at least once. Simulations are useful and they are not the same as standing in a shop with one bar.
There is a point where further work costs more than it returns. For most independent stores, getting LCP under about 2.5 seconds on mobile matters a great deal. Moving a score from 78 to 84 matters very little.
The things that genuinely move the number are almost always the same short list: oversized images, too many apps, render blocking scripts, and heavy fonts. If those four are handled, you have captured most of the available gain.
What remains is often not yours to fix. Some app scripts cannot be deferred without breaking the app, and at that point it stops being a technical question and becomes a business one: is this app earning the milliseconds it costs.
The report is a list of findings with a number stapled to the top. The findings are the product. The number exists so the tool has something to show you in a circle.
If you take one habit from this: screenshot the diagnostics before you change anything. Half of speed work is being able to prove what the change bought.
Related reading: I cut 213 MB of images and it was still slow Your mobile store is not smaller, it is different
Want to know which change buys you the most seconds?
Send me your store URL and I'll read the report properly and tell you what I'd fix first, and what I'd leave alone.
Take the free audit → Or book a call