Your store takes forever to show up on mobile. You read that you should compress your images, you did it, and nothing moved.
That tracks. On most of the Shopify stores I open, the weight comes from the scripts your apps inject into every page, and no screen in your admin tells you which ones.
Here's how I work through it, in order.
Measure before you touch anything
The first mistake is fixing blind. You spend a weekend reworking your theme and you have no way of knowing whether you made things better or worse.
Take a baseline before you open a single file. Google's PageSpeed Insights hands you two separate blocks, and the difference between them matters.
Lab data is a simulated run on Google's hardware. It's useful for comparing a before and an after, because the conditions stay identical. Field data comes from real Chrome visitors over the last 28 days, and that's the one Google feeds into your ranking. A store can post a mediocre lab score with healthy field data, or the other way round.
The numbers that count in that field block are the three Core Web Vitals, each measured at the 75th percentile of real visits: LCP under 2.5 seconds, INP under 200 ms, CLS under 0.1 (web.dev). Anything above that and Google files the page as needing work.
Always test three pages separately: the homepage, one product page, one collection page. They load very different things, and a store-wide average won't hand you anything you can act on. Shopify's own web performance report splits results by page type for the same reason, though its data lags by up to 36 hours (Shopify), which is why DevTools stays your fast feedback loop.
Find which app is dragging the store down
This is where the whole thing gets decided, and it's the step most speed articles skip.
Open your store in Chrome, right-click, Inspect, go to the Network tab, tick "Disable cache" and reload the page. Every file the page pulls scrolls past, with its weight and its timing.
Sort by size, descending. App scripts usually carry the vendor's name in the URL, or come off an external domain you'll recognize on sight. Write down the three heaviest.
Two details in that panel are worth knowing. The Size column shows what came over the wire, with the uncompressed size in grey underneath, so a script that looks like 40 KB can be 300 KB once the browser unpacks and parses it. And the filter row at the top lets you click "JS" to hide everything except scripts, which is the fastest way to see your app stack on its own.
Then do the same run in the Performance tab, recording a full page load. The waterfall shows you what's render-blocking, meaning the files that stop the page from painting until they've arrived.
A review app, a live chat, a discount popup and a heatmap tool loaded together routinely add up to more than a megabyte of JavaScript before your visitor sees a single product.
One case this method won't catch: a store that paints fast but feels sticky under the thumb. That's a responsiveness problem measured by INP, with its own tooling, and I walked through it in the INP article.
The test that settles it
Uninstall a suspect app, wait a few minutes for the cache to clear, measure again. Then reinstall it if the gain doesn't justify losing the feature.
Change one thing per round. Pull two apps in the same afternoon and you'll never know which one paid off.
Watch out for a classic trap here. Uninstalling an app doesn't always take its code out of your theme. Plenty of apps inject tags straight into theme.liquid or into a snippet, and that code survives the uninstall. You end up with orphan scripts loading into nothing.
Search your theme for commented blocks carrying the app's name, and check your store settings on the custom scripts and pixels side too. Duplicate the theme before you edit anything, so a bad guess costs you a rollback and not a night.
Where image weight really comes from
Compressing images is worth doing, just less than you've been told, because Shopify already serves them through its CDN and converts them on the fly for browsers that support the newer formats.
That also answers the CDN question people keep asking me. You already have one. Paying for a second buys you nothing, and Shopify's own theme guidance asks you to serve as much as possible from its CDN so the server can prioritize blocking resources over HTTP/2 (shopify.dev). What's left on your side is avoiding pointless redirects and going through asset_url so your files come off that CDN properly.
The real weight is a 2000 pixel wide image dropped into a slot that renders at 400. Use the Liquid filters to ask for the size you actually display.
{{ product.featured_image | image_url: width: 800 | image_tag:
loading: 'lazy', width: 800, height: 800, alt: product.title }}Two rules. Lazy loading on everything below the fold, never on the main image of your homepage or your product page, or you wreck your LCP. Shopify puts it in the same terms: anything that appears above the fold shouldn't be lazy-loaded. Second rule, explicit dimensions everywhere, so the page stops jumping around while it loads.
The theme and the Liquid underneath
A theme bought off a marketplace usually ships with features you don't use. Carousels, countdown timers, scroll animations, testimonial sliders. Every one of them costs JavaScript.
Age is a factor people forget. Dawn, the free reference theme, is on version 16.0.0 since August 2026, and that release moved the header over to Shopify's customer account experience (Shopify/dawn). If you're running a theme someone forked from an old Dawn in 2022 and never merged since, part of your weight is just accumulated drift.
On the Liquid side, nested loops are the real culprit. A loop over every collection with another loop over every product inside it renders on Shopify's servers and stretches your response time before the browser even starts its work.
Fonts weigh more than people assume. Three families with four weights each is twelve files to download. Two weights are almost always enough.
What doesn't help
Apps that promise to speed up your store add a layer of JavaScript to compensate for other layers of JavaScript. On the stores where I've watched them run, the net gain sits close to zero.
Switching to a "fast" theme without dealing with your apps puts you back in the same spot within three months, because the apps follow you.
And chasing a 100 on PageSpeed makes no commercial sense. Going from 30 to 65 changes the experience your customers have. Going from 85 to 95 costs real money and nobody notices. Shopify says as much in its own docs, that some of what gets measured is your customer's device, network and location, so as long as the overall metric is good, don't lose sleep over individual pages sitting in the moderate band.
When it's worth paying someone
If your store does under a few hundred orders a month, start with the method above. One afternoon with the Network tab open gets you 80% of the diagnosis, and you'll come out of it able to read your own store, which pays off on every technical decision you make afterwards.
It turns into a real job when the slowdown comes from the theme itself, when several apps are tangled into the same handful of files, or when you can't afford to uninstall anything to test in the middle of peak season.
That's what I go through in an audit. I walk the full chain, work out what costs what in milliseconds, and tell you what can be fixed and what can't be fixed without a rebuild. The audit is 590 euros, and I take the whole amount off the bill if you hand me the fixes afterwards.
