It’s almost never the server. Shopify renders pages server-side and serves assets from its own CDN, so the origin speed that dominates self-hosted platforms isn’t your problem. What slows a Shopify store down is what’s been installed on top of it: third-party JavaScript from apps, oversized images, and inefficient Liquid — roughly in that order.
That ordering matters, because most speed work gets spent on the wrong layer.
First, know what you’re measuring
Three tools, three different jobs:
- Shopify’s speed report (Online Store → Themes → Speed) gives you a trend line, not a diagnosis
- PageSpeed Insights tells you which resources are costing you, under Opportunities
- Theme Inspector is the only one that shows you Liquid render time, which is invisible everywhere else
If you skip the third, you’ll never find server-side rendering problems, because they don’t show up as a slow resource. They show up as a slow first byte.
Cause 1: app JavaScript
This is the largest single category on most stores.
Apps that load synchronously stop the browser from rendering until the script downloads and executes. A single render-blocking script of a couple hundred kilobytes can push Largest Contentful Paint back by a second or more on mobile. Stack four of those and the store is slow regardless of how well the theme is written.
Two specific things to check:
Uninstalled apps often leave code behind. Many apps inject script tags, stylesheets, or theme snippets on install and don’t fully clean up on uninstall. Search theme.liquid and the assets folder for the app’s name or domain. Back up the theme before removing anything.
Hand-pasted tracking snippets. If a pixel was added directly to theme.liquid, it’s render-blocking and it’s the old pattern. Shopify’s Web Pixels API runs each pixel in a sandboxed iframe with no DOM access and no ability to block rendering. Moving tracking there is one of the few changes that reliably improves speed without a trade-off — and post-purchase, it’s the only approach that still works now that checkout script injection is gone.
The judgement call is commercial, not technical. Some stores run several heavy apps because the revenue outweighs the speed cost. Others run two redundant popup apps that add nothing. The point isn’t to remove apps. It’s to know what each one costs.
Cause 2: images
On most storefronts the Largest Contentful Paint element is an image — the homepage hero or the main product photo. If that image is a 2MB PNG where a 150KB WebP would do, that’s your LCP, directly.
Shopify’s Liquid image filters generate correctly sized, compressed, responsive sources automatically. Plenty of themes don’t use them properly. Check whether product and collection images carry loading="lazy", and check that the hero image does not — lazy-loading the LCP element is a common own goal, and it delays the exact thing you’re trying to speed up.
Also check that images have explicit width and height. Missing dimensions cause layout shift, which is a separate Core Web Vitals problem with the same root cause.
Cause 3: Liquid
Liquid renders synchronously, top to bottom, on Shopify’s servers. Slow Liquid doesn’t appear as a slow asset. It appears as a slow time to first byte, and most audits misattribute it.
The usual culprits:
- Loops nested inside loops
- Rendering a snippet for every product in a large collection without pagination
- Metafield checks repeated dozens of times on a single template
- Deep DOM structures — Shopify’s guidance is to keep total elements under about 1,500
Theme Inspector will show you exactly which sections are expensive. Without it you’re guessing.
Cause 4: fonts
A <link> to an external font host adds a DNS lookup and a connection before a single character renders. Serving fonts from Shopify’s CDN removes that. Custom fonts also block text rendering until they download unless you handle the fallback deliberately.
Cause 5: the theme itself
Feature-dense themes ship code for features you don’t use, on every page. A lightweight Online Store 2.0 theme typically scores meaningfully better on mobile than a heavy third-party theme carrying identical content.
Warning signs when evaluating a theme: a jQuery dependency, thirty or forty section types, an entire stylesheet loaded render-blocking, no srcset on images.
That said — swapping themes to fix speed is the most expensive possible fix, and it doesn’t address causes 1 through 4. It’s the right move at redesign time, not as a speed intervention.
Cause 6: anti-flicker snippets
A/B testing tools often ask you to add a snippet that hides the page until the test variant loads. That’s a deliberate render delay, and it’s invisible in the code review because it looks like three lines of nothing. If the store runs a testing tool, check for it.
What doesn’t work
Speed optimiser apps. Most inject their own JavaScript to perform deferred loading and image compression that a modern theme already does. You’re adding a script to fix scripts. Measure before and after; if the score doesn’t move meaningfully, uninstall.
Chasing a score. PageSpeed’s number is a proxy. The metrics underneath it — LCP, INP, CLS — are the thing. A store can gain ten points and feel identical.
Going headless for speed. It removes theme overhead and introduces an entire application to maintain. If the store is slow because of app scripts, those scripts follow you.
The order to work in
- Audit installed apps, remove orphaned code from uninstalled ones
- Move tracking to Web Pixels
- Add
deferorasyncto third-party scripts that aren’t needed for first paint - Fix the LCP image — correct format, correct size, not lazy-loaded
- Run Theme Inspector and fix the slowest Liquid sections
- Move fonts to Shopify’s CDN
The first two usually account for most of the available gain. Steps 5 and 6 are where the remaining time goes on stores that have already done the obvious work.