Why your Shopify store is slow, and what actually fixes it

The score is not the problem

Almost every conversation about Shopify speed starts with a number out of PageSpeed Insights and a request to make it green. That is the wrong end of the problem, for two reasons.

The first is that the score is a weighted summary of measurements, and chasing the summary tends to produce work that moves the summary. The second is that Google's own thresholds are the things that actually matter to a buyer: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Those describe experiences. A store can sit at 74 with all three inside their thresholds and be fine, and it can sit at 92 on a lab run and still feel slow to someone on a train.

So start with the three vitals on your best-selling product page, on mobile, and ignore the headline number until the end.

Four things account for nearly all of it

In the order they usually cost the most.

1. Images that were never processed

This is the big one, and it is boring. A hero image exported straight from Figma or supplied by a photographer is routinely two megabytes when the same image at the same visual quality is a hundred and eighty kilobytes as WebP.

Shopify will serve responsive sizes if it is asked to. Plenty of themes ask for one size and let the browser scale it, which means a phone downloads the desktop asset. Product galleries are worse, because they often preload every image in the carousel rather than the one on screen.

How to find yours. Open the product page in Chrome, open DevTools, go to the Network panel, filter to Img, sort by size, and reload. The top three rows are your answer. Write down what they weigh.

2. Apps, including the ones you removed

Every app that injects a script costs you on every page load, and the cost is not the app's own feature. It is a third-party request, a parse, an execution, and often a layout shift when it renders late.

The part that surprises people: uninstalling an app does not always remove its script. Themes get edited during installation, and the edit stays behind. A store that has tried fifteen apps over three years is often still loading four of them.

How to find yours. In DevTools, look at the Network panel sorted by domain and note every request that is not your own store or Shopify's CDN. Then search your theme for script tags and check each one against the apps you currently pay for.

3. Fonts

A custom webfont blocks text from painting until it arrives, unless it is told not to. Two weights of two families is four files, and if they are loaded from a third-party host it is also a DNS lookup and a TLS handshake before the first byte.

Self-host them, subset them to the characters you actually use, and set font-display: swap so text paints in a fallback immediately. This site does exactly that, which is why no request leaves the domain when a page loads.

4. Theme JavaScript that runs before anything is visible

Sliders, mega-menus, currency switchers, sticky headers and animation libraries all tend to initialise on page load whether or not the visitor is anywhere near them. Individually none of them matters. Together they are the reason a product page takes 400 milliseconds to respond to its first tap.

Fix them in this order

1. The three heaviest images on the product template. Highest impact, lowest risk, usually an afternoon.
2. Scripts from apps you no longer use. Free, and it is pure removal.
3. Fonts: self-host, subset, swap. One change, applies to every page.
4. Defer the JavaScript that is not needed for the first screen. More care, more testing, real gains on INP.

Notice that three of the four are removal. Speed work on a Shopify store is mostly deleting things, which is also why it is so often deferred: nobody gets credit for taking something away.

Where the ceiling is

At some point the theme's own architecture sets the limit. A theme that renders the entire mega-menu into the initial HTML, or that ships one CSS bundle for every template, has a floor you cannot get under without changing the theme.

That is the honest reason nobody should sell you a guaranteed PageSpeed score. The budget is a target, and the theme sets the ceiling. Anyone promising a specific number sight-unseen has not looked at your theme.

When it is worth paying for

If the four checks above take you an afternoon and you fix the images yourself, you have captured most of the available gain. That is a genuinely good outcome and it costs you nothing.

Paying for it makes sense when the store is losing money to the delay faster than the fee, when the fix has moved into theme JavaScript where a mistake breaks the cart, or when you want the before-and-after measured properly rather than eyeballed.

Ours is speed optimisation at €1,200 fixed, in three days — a lab and field baseline on both viewports, the image pipeline, fonts and render-blocking scripts, an app audit listing what to remove and what each one costs you, and a before-and-after report. It excludes a guaranteed score, for the reason above.

If you would rather see where speed sits against everything else that is costing you conversions, that is section two of the Store Teardown, and the audit checklist walks the whole thing.