The Shopify apps quietly slowing your store down
Most slow Shopify stores are slow because of apps rather than theme code. Every app that injects a script adds render-blocking weight to every page, including pages where the app does nothing at all. Auditing and removing unused apps routinely does more for performance than any amount of theme optimisation.
When a store is slow, the instinct is to optimise the theme. On Shopify that is usually the wrong place to start, because the theme is rarely the biggest contributor.
The mechanism
Most apps add frontend functionality by injecting JavaScript. That script is added to your theme, and it loads on every page — not only on the pages where the app is actually used.
A review widget needed on product pages loads on your home page. An upsell tool needed at cart loads on your privacy policy. A currency converter loads on your blog. Each is small. Twenty of them are not, and they all compete for the same single main thread that also has to respond when a customer taps a variant selector.
This is why two stores on the same theme can differ enormously in speed.
Audit before you optimise
Doing theme work on a store carrying twenty apps is treating the symptom. The audit comes first, and it is straightforward.
Step 1 — List every app, and what it does
For each installed app, write down:
- What problem it solves
- When it was last actually used or configured
- Whether the platform has since built the feature in
- Whether another installed app does something similar
That fourth question finds the most. Stores routinely run two apps that both do product recommendations, or three that all touch the cart.
Step 2 — Establish what each one costs
Measure the store with the app active, then in a duplicate theme with it removed. What you are looking for is the change in total JavaScript, in main-thread work, and in interaction responsiveness.
Some apps cost almost nothing. Others are startling. You cannot tell which is which by reading the app listing.
Step 3 — Decide, honestly
For each app: does the revenue or time it produces exceed what it costs in subscription and in speed?
For a genuinely effective upsell tool, often yes. For a currency converter on a single-market store, or a popup nobody has updated in a year, almost never.
Step 4 — Check what uninstalling leaves behind
This is the step everyone skips.
Apps built as theme app extensions remove cleanly. Apps that injected script tags or edited theme files often leave fragments behind. Those fragments then load forever, doing nothing, for an app you no longer pay for.
After uninstalling, search the theme for the app’s name and any script domains it used. We have found remnants of apps removed years earlier still loading on every page view.
What to look for specifically
Categories that most often cost more than they return:
- Popup and email capture tools — frequently load a large bundle for a modal
- Review widgets — value varies enormously by implementation
- Currency and geolocation switchers — Shopify Markets handles much of this natively now
- Multiple analytics tools — each adds a script, and most stores use one properly and ignore two
- Anything installed for a campaign that ended
That last category is the most common and the easiest to remove.
What to do with what remains
Once the list is genuinely necessary:
- Prefer apps built as theme app extensions. Scoped loading, clean removal.
- Ask whether metafields would do it. A great deal of what stores install apps for is structured product data, which Shopify handles natively at no monthly cost. See the custom Shopify build guide.
- Ask whether Shopify Functions would do it. Discount and shipping logic runs natively rather than through an app.
- Load what remains as late as possible, and never let a third-party script block first render.
Then optimise the theme
With the app list honest, theme work becomes worth doing: image sizing and formats, above-the-fold render order, removing unused CSS, deferring non-critical scripts.
That work matters. It is simply not where the biggest win is on most stores, and doing it first means fixing the small problem while the large one keeps growing.
Review it on a schedule
Apps accumulate the way subscriptions do — one at a time, each justified individually, never reviewed as a set. Audit at launch and every six months afterwards.
It is usually the fastest performance win available, and it saves money at the same time, which is a rare combination.
Building the habit
An app audit is not a one-off task. Apps accumulate the way subscriptions do, and the only defence is a routine.
At launch. Every app justified, documented, and its performance cost measured. Write down what each does, so the next person is not guessing.
Every six months. Full audit against the four steps above. Half a day, and it reliably finds both money and speed.
Before every peak trading period. The worst time to discover an app is slowing checkout is during your busiest week. A shorter check — measure, compare against last time, remove anything obviously unused — takes an hour.
Whenever somebody wants to install one. A single question at the point of installation: what problem does this solve, and what happens to it when that problem passes? Most unnecessary apps are installed to solve a temporary problem and never revisited.
What to measure
If you want numbers rather than impressions, measure these before and after each change:
- Total JavaScript transferred on a product page and on the home page
- Main-thread work, which is where app scripts actually cost you
- Interaction responsiveness, because variant selection and cart interactions happen after load
- Largest Contentful Paint, on mobile, throttled
Test on a duplicate theme rather than live, and test the same page each time so comparisons mean something.
The reason to measure rather than assume is that app cost varies enormously and unpredictably. A visually simple app can ship a large bundle; a complex-looking one can be well built and nearly free. You cannot tell from the listing, and you cannot tell from the price.
The wider point
Every app is a decision to accept somebody else’s code, running on every page, in exchange for a feature.
Frequently that is a good trade — the ecosystem contains genuinely excellent work, and building the same functionality yourself would cost far more. The problem is not any individual trade. It is that the trades accumulate, nobody reviews the total, and a store ends up carrying twenty of them when it actively uses six.
A short version
If you remember one thing: audit before you optimise. Doing theme work on a store carrying twenty apps is fixing the small problem while the large one keeps growing, and it is how performance budgets get spent for very little return.
Before you start
Take a measurement of your product page today, on mobile, throttled, and write the numbers down. Everything in this article is easier to act on when you can see whether it worked, and impossible to justify afterwards when you cannot.
