My store feels fast, so why is my mobile PageSpeed score so low?

Your store feels fast to you because you open it on a quick computer or a recent phone, usually on good Wi-Fi, with most of its files already saved in your browser from earlier visits. The mobile PageSpeed test loads the page on an emulated phone with a slowed-down connection and processor, without those saved files, and on that kind of setup the scripts, images and add-ons on a typical store page take much longer to load and run.

A low mobile score tells you the page carries more than a slower phone handles comfortably. It doesn't tell you, on its own, whether real shoppers are suffering. PageSpeed Insights has a second section that answers that, and it is the one Google Search pays attention to.

The test doesn't load your store the way you do

When you open your own homepage, your browser has probably seen it hundreds of times. The logo, the fonts, the theme's stylesheets and a good part of the JavaScript are already stored on your device, so the browser only fetches what changed. A new shopper arriving from a Google search or an Instagram ad has none of that. Every file comes down fresh, and the lab test behaves the same way.

The processor matters as much as the connection. A modern laptop runs JavaScript far faster than an average phone, so code that starts up unnoticed on your desk can make a cheaper Android phone stall for a moment after the page appears. If a shopper taps "Add to cart" during that moment, nothing happens, and they tap again or leave.

Google's PageSpeed Insights documentation says the lab data is collected in a controlled environment with predefined device and network settings. The Lighthouse throttling documentation explains that for mobile it slows down both the network and the processor on purpose, so the result reflects a phone that is a good deal less powerful than the one in your pocket.

The score and the real-shopper data are two different things

A PageSpeed Insights report has two parts. The big colored number, the performance score from 0 to 100, comes from a single lab run by a tool called Lighthouse. The Lighthouse scoring documentation describes it as a weighted mix of several timing measurements, and notes that it can change from one run to the next even when nothing on your site has changed. Running the test three times and getting three different numbers is normal.

The other part sits above the score, in the section about what your real users are experiencing. That comes from the Chrome UX Report, which collects anonymous speed data from Chrome users who actually visited your site, over the previous 28 days. It shows whether your pages pass Core Web Vitals, Google's measurements of loading speed, responsiveness to taps and visual stability. If your store doesn't get enough traffic, this section says there isn't enough data, and the lab score is all you have.

Google's page on Core Web Vitals and search results describes these as measurements of real-world user experience and says its ranking systems use them. In the report, those real-world numbers live in the real-user section, which is why we read it before the score. A low lab score next to a passing real-user section can happen, and so can the opposite. Our post on Core Web Vitals for ecommerce explains what each measurement means for a store.

If the real-user section fails on mobile, real shoppers are having a slow time and the lab results are a good map of why. If it passes, the low lab score is still worth working on, though with less urgency than the red number suggests.

What usually drags an online store's mobile score down

On ecommerce sites the heaviest cost is usually JavaScript, and most of it doesn't come from the store platform itself. It arrives with things added over the years: WooCommerce plugins, PrestaShop modules and Shopify apps for reviews, wishlists, upsells and pop-ups, plus chat services, advertising pixels and Google Tag Manager with more tags inside it than anyone remembers. Each seemed small when it went in. On a slow phone they all compete for the same processor while the page is trying to become usable. Lighthouse counts that busy time as Total Blocking Time, and according to its scoring documentation it carries the largest single weight in the mobile score, 30%.

The second common cause is the first big thing on the screen, usually a hero image or a homepage slider. Lighthouse measures how long the largest visible element takes to appear (this is called Largest Contentful Paint, and it carries 25% of the score). A full-width photo saved at a size meant for a large monitor, or a slider that waits for its own script before showing the first slide, can hold that moment back by seconds on a mobile connection. Sliders are common in store themes, and a single well-sized static image usually does the same job and loads much sooner.

After those come web fonts loaded from several places, cookie banners that need their own script before the page can show, page builders that wrap every block in extra layers of code, and on WooCommerce, pages the server builds slowly because caching isn't set up or doesn't cover them. A slow server is something you would normally feel yourself, though. If the store genuinely feels quick on your own devices, the cause is more likely in what runs in the browser after the page arrives.

How to find what is slowing your mobile pages

You can get a fair picture yourself with the free tool and an ordinary phone.

1. Test the pages that earn money, not only the homepage. Run PageSpeed Insights on a category page and a busy product page as well, since they often load different scripts.
2. Read the real-user section and note whether mobile passes or fails, and which measurement is the problem.
3. In the lab results, check which individual measurements are red. A poor Total Blocking Time points to scripts. A poor Largest Contentful Paint points to the main image, fonts or a slow server response.
4. Scroll down to the diagnostics and look for the entries about JavaScript, third-party code and the largest content element. They usually list specific files and domains, which tells you which plugin, module or app they belong to.
5. Open your store on an ordinary phone, in a private browsing window, on mobile data rather than Wi-Fi. That is closer to a new shopper's visit than anything on your desk.

Once you know which add-on is heavy, test switching it off on a staging copy of the store, a private duplicate where breaking things costs nothing, and take a fresh backup of the live store before changing anything there. Turning a plugin off on the live site carries the same risk as removing it, since checkout or product pages can break the moment it goes. Be careful with uninstalling too. Some WooCommerce plugins and PrestaShop modules delete their settings and data when removed, so a reviews plugin can take your collected reviews with it. On Shopify, some apps leave code in the theme after they are uninstalled, and that code keeps loading on every page until someone removes it from the theme files.

For WooCommerce stores, our step-by-step WooCommerce speed guide covers caching, images and scripts in more detail, and PrestaShop owners can follow the PrestaShop speed optimization guide.

How far to chase the number

A store doesn't need a mobile score of 100. Stores carry analytics, payment buttons and reviews that a plain blog doesn't, and stripping out tools you actually use to please a lab test is a bad trade. We would aim for real-user Core Web Vitals passing on mobile, and a lab score that isn't being held down by scripts nobody uses anymore.

Large jumps are possible when the store is rebuilt with phones in mind. On Kozelj.net, the old store's home page scored about 42 on mobile PageSpeed and the new one about 92, with the main content appearing in under 3 seconds instead of about 15. That came from a rebuild, which isn't the right answer for every store, and the results page describes what changed.

Smaller fixes, like removing an unused app or resizing the hero image, show up in the lab score as soon as you rerun the test. The real-user section moves more slowly, because it averages the last 28 days of visits, so check it again about four weeks after a change before judging whether it worked.

Want us to look at your store? Book a call.