How Many Shopify Apps Is Too Many

The question gets asked as though there is a number, and there is not. Apps differ by orders of magnitude in what they cost you, so counting them measures the wrong thing entirely.

A store with twenty well-built apps using theme app extensions and loading only where needed can be faster than a store with five that inject scripts globally. The count is identical to a merchant and meaningless to a browser.

Find out in ten minutes

This is not a project. It is a browser tab.

Open a product page in Chrome. Open DevTools, go to the Network tab, disable cache, and reload. Filter to JS and sort by transfer size.

You now have a ranked list of every script the page loads and what each costs. Repeat on your homepage and your cart, because they differ.

What you are looking for:

Third parties you do not recognise. Almost always apps, and sometimes apps you no longer use.

Scripts on pages where their feature does not appear. A review widget on your blog. A popup tool at checkout. This is the most common finding and the most fixable.

Duplicate functionality. Two analytics tools, two review systems, or two separate things doing popups.

Anything surprisingly large. A single script over a few hundred kilobytes should have a justification.

That list is your audit. Everything else is acting on it.

Reading what the Network tab actually shows you

The list DevTools produces is not self-explanatory the first time you look at it, so it helps to know what a typical row means before deciding what to do about it.

Each row shows a filename, usually hosted on a domain that is not yours, for example something ending in a vendor's own domain rather than your store's. The Size column shown by default is the compressed transfer size, which is the number that matters for load time. A script showing 40 KB transferred but 200 KB uncompressed is still costing you the 40 KB on every visit; the larger figure only matters if you are curious how much work the browser does after downloading it.

The Time column tells you how long that request took to complete, and Waterfall, the small chart on the right of each row, shows when it started relative to the rest of the page. A script that starts loading only after everything else has finished is deferred, and it is doing less damage than one competing for bandwidth in the first second, even if its file size is identical.

Click a row and the Initiator column, visible in the request details, tells you what caused the script to load: often another script, which means one app pulled in a second one you never installed directly, such as an analytics library bundled inside a review app. This is worth tracing, because removing the app you can see does not remove the second script if something else on the page still calls for it.

A practical way to work through the list: sort by size, take the top five, and for each one ask what feature it is meant to support and whether that feature actually appears anywhere on the specific page you are looking at. A 150 KB script supporting a feature visible nowhere on this product page is the clearest kind of finding this exercise produces, and it is usually the first thing worth investigating rather than removing outright, since the same script may be doing real work on a different template.

The three categories of waste

Almost all app-related weight falls into one of these.

Apps you no longer use. Trialled, forgotten, still installed and still loading. Nearly every store has some. Compare your billing against what is actually live on the storefront — the two lists rarely match.

Apps loading globally for a local feature. The app supports something on product pages and loads on all eight hundred URLs. Some apps let you scope this; many do not, and that constraint should factor into whether you keep them.

Residue from uninstalled apps. The one merchants never check. Apps that wrote snippets into theme files rather than using theme app extensions frequently leave that code behind. It keeps loading, does nothing, and costs weight indefinitely.

That final item matters. Removing a script you cannot identify is how a store loses its conversion tracking three days before a campaign.

Weight is not the only cost

Worth naming the others, because they influence which apps to remove first.

Conflict. Two apps touching the cart will eventually disagree. Two doing popups will show a customer two popups. Overlapping apps are a source of bugs nobody attributes correctly, because each vendor points at the other.

Dependency. Every app is something that can break, change its pricing, or be discontinued. An app doing something central to how you sell is a business dependency.

Cognitive load. A store with thirty apps is a store nobody fully understands. When something breaks, the diagnosis is longer, and the person who knew why an app was installed has usually left.

Subscription creep. Individually small, collectively significant, and almost never reviewed once set up.

What good looks like

Rather than a target count, a set of properties:

A store meeting those can carry a lot of apps comfortably. A store failing them is in trouble at any number.

When custom work replaces apps

There is a threshold, and it is worth knowing rather than reaching accidentally.

Custom development starts to make sense when several conditions coincide: you are paying for three or four apps to produce one outcome, those apps conflict with each other, the function is genuinely specific to how you sell, or the combined monthly cost has grown to where a build pays back within a year or two.

The trigger most merchants notice first is conflict rather than cost. When two apps fight over the cart and both vendors point elsewhere, replacing both with one piece of logic that does exactly what you need stops feeling expensive.

Below that threshold, apps are the cheaper answer and building is over-engineering.

What to remove first

Once you have the list, the order matters — some removals are free and some carry risk.

Start with what is not running anything. Apps you pay for whose feature is nowhere on the storefront. Zero risk, immediate saving, and it is usually the largest single category.

Then the residue. Theme code from apps already uninstalled. Nothing depends on it because the app is gone. The only care needed is confirming the snippet genuinely belongs to a removed app before deleting it.

Then duplicates. Where two apps do the same job, pick one and remove the other properly. Do not leave both installed while you compare — that comparison never concludes and you pay twice indefinitely.

Then the heavy ones you can live without. This is where judgement enters, because you are trading a feature for speed. Remove one, measure conversion and page speed for a fortnight, and decide on evidence rather than instinct.

Last, the load-bearing ones. Apps central to how you sell should be replaced rather than removed, and only when you have something ready to take over.

The sequencing matters because the first two categories are free wins that build confidence, and they frequently recover enough weight that the harder decisions become unnecessary.

Make it a habit, not a project

The reason this recurs is that app stacks accumulate. Every campaign adds one, every trial leaves residue, and nobody removes anything because removal has a small risk and inaction has none.

Two practices prevent it:

Audit annually, in a quiet trading period. An hour with DevTools open and your billing page beside it is the whole exercise.

Note the date when you install something, and what you expect it to do. Then you can evaluate it later against something other than vague recollection.

A short shared document is enough for both. One line per app: what it does, when it was installed, who asked for it, and what it was supposed to achieve. That record is worth more than it sounds, because the most common reason an app survives an audit is that nobody can remember why it is there and nobody wants to be the person who removed something important.

The cost nobody counts

Beyond weight and subscriptions, an app stack has an operational cost that only becomes visible when something goes wrong.

When a store breaks — a discount not applying, a page rendering incorrectly, checkout behaving oddly — the diagnosis begins by working out which of your installed apps could be responsible. With five apps that is quick. With thirty it is an afternoon, and it is an afternoon during an incident.

The same applies to platform changes. Every Shopify release is a set of things that might interact with what you have installed, and a larger stack means a larger surface for that. Merchants with many apps discover platform changes through breakage rather than through release notes.

None of this argues for a minimal stack as a virtue in itself. It argues for every app being deliberate, because the ones that are not deliberate are the ones that make the incidents longer.

For app selection within specific categories, see Shopify apps. The performance side is covered in storefront and design, and the build-versus-buy question in Shopify development.