A recent audit on a UK apparel store told the same story I hear at the start of most performance engagements. The merchant believed his store was slow because of "Shopify #101 mistakes" in the theme. Real numbers told a different story. The store had 24 apps installed. Twelve of them were injecting code on every page render via theme embeds. The homepage was loading 7.99 MB of assets and taking 11 seconds to reach Largest Contentful Paint on a throttled mobile connection. The theme itself was unremarkable — a standard paid Shopify theme, maintained, not bloated. What was bloated was everything sitting on top of it.

This pattern is the rule, not the exception. The cheapest, fastest, least risky performance gain available to most established Shopify stores isn't a theme refactor or a CDN swap. It's an honest accounting of what's installed.

What an app actually does to your page

Each Shopify app you install can touch your storefront in three ways. It can register a theme app embed via settings_data.json — code that runs on every page even if you never use the app's feature on that page. It can inject script tags through the Online Store editor. And in some cases it can ship Liquid customizations directly into your theme files.

One real example from the audit above: a single SEO app contributed seven separate theme embeds. One app, seven discrete pieces of JavaScript loading on every page. The merchant was paying around $24/month for it, and the work the app was doing — structured data output, meta tag templates — was something the underlying theme had started handling natively two releases earlier. The app had outlived its job.

That's just the apps currently installed. There's a second tier that matters more than the first.

Orphaned code is worse than active apps

When you uninstall a Shopify app, the subscription stops, the admin link disappears, and the app vanishes from your Apps page. What doesn't always vanish: the theme embeds it registered, the asset references it left behind, the metafields it created. The settings flag flips to off, but the code can stay loaded.

In the same audit, an old marketplace-integration app — uninstalled eight months earlier — was still contributing roughly 147 KB of orphaned JavaScript on every page request. The merchant was paying nothing for it. He'd actively decided he didn't need it. And it was still running.

The cleanup costs nothing. The performance gain is permanent. The risk is near-zero because the code was supporting a feature you already decided to live without.

The diagnostic step is unglamorous and takes about thirty minutes. Open config/settings_data.json. List every theme embed currently active. Cross-reference that list against the apps installed in your admin. Anything in the embeds list that isn't in the installed-apps list is orphaned and safe to disable. The Online Store editor exposes the same controls under App embeds in the theme customizer; you don't need to touch the file directly if you're not comfortable doing so.

Three categories of installed apps worth questioning

For apps that are still actively installed, three patterns show up in nearly every audit I run.

1. Apps that solved a problem your stack has since absorbed.

The SEO app I mentioned earlier is the canonical version of this. So is the schema-generator app installed before Shopify's own structured data improved. So is the "speed booster" app installed before Online Store 2.0 made several of its functions redundant. The test for this category is simple: if I uninstalled this today, what specifically would stop working? If you can't name a concrete missing feature within thirty seconds, the app is probably in this category.

2. Apps that overlap with another app you also installed.

Two review apps where customers see one and the other is just loading. Two analytics layers where one is wired to your reports and the other was a trial that never got cancelled. The most common pattern: the marketing team installed app A, a dev contractor installed app B six months later without knowing about A. Both load on every page render; only one is integrated with anything. The fix is fifteen minutes and a polite conversation about who owns the app inventory.

3. Apps that solved a one-time problem.

A bulk-edit tool from a product migration. A theme-checker installed at launch. A migration helper from a previous theme switch. These often have legitimate, valuable uses for a defined window — and then they sit on the store for eighteen months loading scripts on every page. The remedy is a calendar reminder at install time: review this app in 90 days.

What it actually costs to remove an app

For most apps, removal is straightforward. Disable the embed in the theme editor. Uninstall through the admin. Audit settings_data.json and the theme files for orphaned references. Re-test the affected page templates. Total time: typically 15 to 30 minutes per app, often less.

There are three categories where it's harder, and worth flagging honestly:

  • Apps wired into checkout. These usually need a parallel rebuild before removal — checkout extensibility means swapping out a checkout app is rarely a one-step operation.
  • Apps with their own data store that customers depend on. Review history, loyalty points, subscription state. These need an export migration into either the theme, a metaobject, or a replacement app — not a clean uninstall.
  • Apps that ship Liquid customizations into your theme. Their assets and references often stay behind after uninstall. The cleanup is real work, not zero work.

But these are the exception. For the seventy-to-eighty percent of installed apps that are just "loads scripts on every page," the removal is genuinely small work with permanent benefit.

The math

In the audit I keep referring to, the merchant was paying somewhere around $90/month for apps that either overlapped with another app or had been functionally replaced by the theme. That's $1,080 a year of cash savings before you count any performance gain at all. After cleanup, embed count moved from twelve to six. Homepage LCP began to drop. The audit itself cost less than two months of those unused subscriptions.

The performance numbers move because every script you remove is a script the browser no longer has to fetch, parse, and execute on the critical render path. Each app embed typically adds 30 to 200 KB of JavaScript, network requests against third-party domains, and CPU work during page render. Compounding effects are real: removing six embeds doesn't just reduce weight linearly, it frees up the browser's main thread to render the parts of the page you actually care about earlier.

When to do this work

Two natural triggers. The first: you're considering a theme migration or replatform because the site feels slow. Do the app audit first. Half of the "theme bloat" merchants attribute to their current theme turns out to be app weight that would follow them onto any new theme on any platform. The second: your Core Web Vitals are failing and SEO is suffering. The app audit moves the needle faster and cheaper than almost anything else you can do.

If you're DIY-capable, you can run the first pass yourself. Count the active theme embeds in settings_data.json. Cross-reference against installed apps. Note anything orphaned. List the active apps and ask, for each one, whether you can name a specific feature that depends on it. If the list looks bigger than you expected — or if any of the harder categories show up — that's the right moment to bring in a paid audit. It's the cheapest performance win available, and it pays for itself in the first month.