Shopify app bloat: how too many apps are killing your store's performance

The tax you pay on every page load

Every Shopify app you install makes a promise. More reviews, more upsells, more personalization, more revenue. What almost none of them mention is the tax you pay on every single page load, whether the app is doing anything useful on that page or not.

That tax is JavaScript. A typical app adds somewhere between 50KB and 150KB of it to your storefront, and it runs on every page regardless of context. A review widget that only matters on product pages still loads on your homepage, your cart, and your checkout confirmation. A loyalty popup built for returning customers still fires its script for a first-time visitor who bounces in four seconds. None of that code cares whether it's needed. It just runs, and it competes with everything else on the page for the same single-threaded resource: the browser's main thread.

This is why app accumulation is the most common cause of performance decline on stores that have been live for more than a year. Nobody sits down one day and decides to slow the store down. It happens one install at a time, usually to solve a real short-term problem, and the cumulative cost only becomes visible months later when Core Web Vitals start slipping and nobody can point to a single cause.

What each app actually costs you

Removing an unused app typically shaves 150 to 300 milliseconds off Largest Contentful Paint. Stack ten apps that were installed for good reasons at the time, and you can be looking at more than a second of avoidable delay before your hero image or headline even finishes rendering. Adding five or more apps drops the average mobile PageSpeed score by 15 to 25 points, which is often the difference between a passing and a failing Core Web Vitals report in Google Search Console.

Interaction to Next Paint is where this gets worse than most merchants expect. INP now measures every interaction across a full session, not just the first click. That means a bloated app stack doesn't just slow your homepage load. It makes the Add to Cart button feel sluggish, it delays the checkout step transitions, and it does this on mobile, where 79% of Shopify traffic and the majority of your conversion opportunity actually lives.

The categories that do the most damage, in order, are popups and overlays, review widgets, personalization or recommendation engines, loyalty programs, and live chat. These share a pattern: they're built to run everywhere, load early, and hook into the DOM in ways that block rendering until they're done.

Why "we're not using it much" isn't the right test

The instinct when auditing apps is to ask which ones get used the least. That's the wrong question. The right one is which apps are running code on pages where they contribute nothing, and how much that code costs you in aggregate. A well-used review app that only loads its script on product detail pages is fine. The same app configured to load globally, including on your cart and account pages, is quietly taxing every visitor for a feature only a fraction of them will ever see.

Uninstalling an app doesn't automatically solve this either. Shopify removes the app's admin access, but leftover script tags, orphaned theme sections, and stray CSS files routinely stay behind in the theme code. We see this constantly in audits: a merchant swears they removed a popup tool eight months ago, and its script is still injecting itself into `theme.liquid` because the uninstall never touched the code the app left behind.

How to actually audit your app stack

Start in Shopify Admin under Apps and list everything installed, active or not. Cross-reference that list against a PageSpeed Insights run and the Network tab in Chrome DevTools, filtered to third-party requests. This tells you two things at once: which scripts are loading on which pages, and roughly how much weight each one adds.

From there, disable apps one at a time, ideally in a staging environment, and re-run PageSpeed Insights after each change. This isolates the actual LCP and INP impact of each app rather than guessing from the aggregate. For every app still standing after that pass, ask three questions. Is it actively used and can you point to the last time someone touched it. Is it driving revenue you can measure, not just a feature that felt nice to add. And is there a lighter alternative, including Shopify's own native tools, that does the same job for less weight.

Search & Discovery, for example, replaces most third-party filtering and search apps at no additional performance cost, since it's built into the platform rather than bolted on. The same is often true for reviews, basic upsells, and even some personalization use cases that don't need a dedicated third-party engine.

What to do with the apps you can't remove

Some apps earn their keep and stay. For those, the fix isn't removal, it's control. Script deferral using `async` or `defer` attributes keeps non-critical scripts from blocking the initial render. Conditional loading by page type means your review app's script only fires on product pages instead of everywhere. And for logic that's currently handled by a third-party app but doesn't need to be, migrating that logic to a native Shopify Function moves the work off the storefront's JavaScript entirely and runs it server-side instead, which is a meaningfully different performance profile.

We ran exactly this audit for a mid-size DTC client last year: 14 installed apps, several with scripts loading globally that only needed to run on a handful of URLs. After removing four apps outright, scoping the rest to the pages where they actually mattered, and deferring what remained, mobile LCP dropped by more than a full second and the store moved from failing to passing Core Web Vitals in Search Console within one reporting cycle. Nothing about the store's functionality changed. The apps that stayed still did their jobs. They just stopped doing it on pages where nobody needed them.

Measuring whether the fix actually worked

Don't stop at a single PageSpeed Insights run and call it done. Lab data from PageSpeed is useful for diagnosis, but it's a simulated single visit, not what your real customers experience across different devices and connections. The number that actually matters lives in the Core Web Vitals report inside Google Search Console, which uses field data collected from real visitors over a rolling 28-day window. That's the report Google uses for ranking, and it's the one that tells you whether your app cleanup produced a lasting improvement or just a good Lighthouse score on the day you tested it.

Give it time to update after any change. Because the Search Console report rolls over a 28-day window, you won't see the full picture for at least a few weeks after removing or deferring apps. Check it again a month out, and again after any seasonal campaign, since holiday popups and promotional banners added for a sale event are one of the most common reasons a store that passed Core Web Vitals in October fails it again in December.

The bigger pattern

App bloat rarely comes from a single bad decision. It comes from a dozen reasonable ones made over a year or two, each solving a real problem at the time, none of them revisited once the problem was solved or the app quietly stopped delivering. Treat your app stack the way you'd treat any other recurring cost: audit it on a schedule, not just when something breaks.

If you want a clear picture of exactly which apps are costing you the most and where the highest-impact fixes are, Shugert's Shopify performance work starts with this kind of audit before touching a single line of theme code. For the full playbook on ranking those fixes by leverage, our Shopify performance optimization guide walks through everything we ship, in order.

Questions worth asking before your next app install

1. Will this app's script load on every page, or only where it's actually needed?

2. Do you already have a native Shopify feature that does 80% of what this app promises?

3. Who on your team is responsible for re-auditing this app in six months?

4. If this app disappeared tomorrow, would anyone notice besides the invoice?