How many apps are slowing down your Shopify store (and what to cut first)

Key takeaways

• Every Shopify app you install adds JavaScript, CSS, and often a third-party script tag that loads on every storefront page, whether that app is doing anything useful on that page or not.
• Page speed is a direct input into Core Web Vitals, and Core Web Vitals affect both how Google ranks you and how many visitors convert before they give up waiting.
• The fix isn’t “use fewer apps” as a blanket rule. It’s knowing which apps are earning their weight in load time and which are dead code you forgot to remove.
• A practical audit measures each app’s actual performance cost against the revenue or function it delivers, then cuts anything that fails that test.

---

Why does installing more Shopify apps slow down your store?

Every app you install adds its own JavaScript file, and most inject that file into your theme’s global layout, meaning it loads on every single page, not just the page where the app does something. A store running a long list of apps is often loading a separate script for each one before a visitor can add anything to cart, regardless of whether that visitor ever touches the feature those scripts support.

Shopify makes installing apps frictionlessly easy. That’s the appeal and the problem. A reviews app, an upsell popup, a currency converter, a live chat widget, a countdown timer, a size guide, an email capture tool, a loyalty program, a shipping calculator; each one solves a real merchant problem in isolation. None of them were built with awareness of the other apps already running on your theme.

The technical mechanism is straightforward:

• Script tags load synchronously by default. Many apps inject <script> tags that block the browser from rendering the page until that script has downloaded and executed, even if the app’s actual function (a popup, a widget) isn’t needed until later or ever.
• Apps make their own network requests. Beyond the initial script, most apps then call out to their own servers to fetch configuration, personalisation data, or tracking pixels, adding round trips the browser has to wait on.
• CSS gets injected globally. Styling for an app widget often loads on every page rather than just the page or component that uses it, adding render-blocking weight the browser has to process before it can paint anything.
• Apps rarely clean up after themselves. Uninstalling an app frequently leaves orphaned script tags, unused metafields, or leftover theme code, because most app uninstall flows don’t fully reverse what the install did.

None of this is unique to any one app vendor. It’s a structural consequence of how the Shopify app ecosystem is built: every app operates independently, but every app’s cost lands on the same shared resource, which is your page load.

How does slow page speed actually cost you sales?

Slower pages lose visitors before they convert, and the drop-off is steepest in the first few seconds of load time. This isn’t a vague correlation, it’s how browsers and shoppers behave: a visitor who taps a product link on their phone and watches a blank screen for several seconds doesn’t wait around wondering if your reviews widget is worth it. They go back to the search results or the Instagram feed they came from.

Two things happen at once when your store carries app bloat:

Google factors page speed into ranking, via Core Web Vitals. Google’s Core Web Vitals measure three things: how fast the main content loads (Largest Contentful Paint), how quickly the page responds to the first interaction (Interaction to Next Paint), and how much the layout shifts around while things load (Cumulative Layout Shift). Shopify apps are frequent culprits behind poor scores on all three, render-blocking scripts delay LCP, heavy JavaScript execution delays INP, and late-loading widgets (a popup that shoves content down, a reviews badge that pops in above the fold) cause CLS. If organic search matters to your store’s traffic mix, slow pages are a ranking headwind on top of a conversion problem.

Slow pages lose the conversion before the visitor ever reaches your offer. Baymard Institute’s research on page abandonment consistently finds load speed among the top reasons shoppers leave before completing a purchase, particularly on mobile, where slower connections and smaller patience thresholds compound the problem. A slow product page doesn’t just convert worse, it doesn’t get the chance to convert at all for a share of visitors who never wait for it to finish loading.

The two effects stack. A slow store shows up less often in organic search, and converts a smaller share of the traffic it does get. That’s the double cost of app bloat, and it’s why this sits squarely in conversion rate optimisation, not just a technical housekeeping task.

How do you find out which apps are actually slowing your store down?

You audit each app’s real performance cost using browser dev tools and Shopify’s own theme inspection, rather than guessing based on how “heavy” an app feels. Here’s a practical sequence:

1. Baseline your current speed with Google PageSpeed Insights or Lighthouse

Run your homepage, a representative product page, and your cart page through PageSpeed Insights. Note your Core Web Vitals scores and, specifically, your total JavaScript payload and number of render-blocking resources. This is your before number, and you’ll want it before you start removing anything so you can prove the impact of what you cut.

2. Open the network tab and watch what loads

In Chrome DevTools, open the Network tab, filter by JS, and reload a product page. You’ll see every script your theme and every app is pulling in, along with its size and load time. Apps typically announce themselves in the file name or domain (a reviews app calling out to its own CDN, a chat widget loading from its own subdomain). This is the fastest way to see, concretely, which apps are contributing the most weight rather than relying on the app’s own marketing claims about being “lightweight.”

3. Cross-reference against Shopify’s theme code

Go to Online Store > Themes > Edit code and search theme.liquid and your layout files for <script> tags referencing app domains. Many apps also drop snippets into individual template files. This tells you not just what’s loading, but where, and whether it’s loading globally (every page) or contextually (only where it’s actually used).

4. Score each app against what it’s actually doing for you

For every app on the list, ask two questions:

• What is this app’s measurable performance cost? (script size, number of requests, effect on LCP/INP when disabled in a test)
• What is this app’s measurable business function? (a reviews app that visibly lifts add-to-cart rate on product pages is doing something a rarely-opened size guide widget isn’t)

An app with a real script cost that drives visible engagement on your highest-traffic pages is a different decision to an app with the same script cost that fires on every page for a feature almost nobody uses. Weigh cost against function, not cost in isolation. The goal isn’t a zero-app store, it’s a store where every script earns the milliseconds it takes.

What’s the cut-first framework for reducing app bloat?

Cut apps in this order: unused apps still installed, apps duplicating a function your theme already has natively, apps loading globally but used on a handful of pages, then apps you can replace with a lighter alternative or custom code.

Tier 1: Cut immediately, no trade-off

Apps you installed and stopped using. Every Shopify store accumulates these: a trial for a Black Friday promotion that never got uninstalled, a competitor comparison tool nobody looks at, an old email popup replaced by a newer one but never removed. These carry full performance cost and zero function. Audit your installed apps list against what’s actually visible and active on your live theme, not just what’s sitting in your app dashboard.

Apps duplicating something Shopify or your theme already does. Many themes now include native image optimisation, basic upsell blocks, or simple countdown functionality. If you installed an app for something your theme already handles, you’re paying twice, once in theme weight, once in app weight, for the same outcome.

Tier 2: Cut or restrict scope

Apps that load globally but only function on specific pages. A size guide widget only needs to load on product pages for apparel, not on your blog, your cart, or your collection pages. If the app doesn’t support conditional loading in its own settings, this is where a developer can scope the script tag to load only where it’s needed, cutting the performance cost on every other page without losing the function anywhere it matters.

Apps with a heavier free or lower tier than you need. Some apps load extra tracking, upsell, or analytics scripts bundled into their base install regardless of which features you’ve actually turned on in the app’s settings. Check the app’s settings panel for options to disable unused modules before assuming the whole app has to go.

Tier 3: Keep, but verify

Apps directly tied to revenue you can measure. A reviews app on product pages, an upsell tool with a track record of lifting average order value, a well-implemented cart drawer; these earn their cost if the function is genuinely converting. The test here isn’t “does this feel important”, it’s whether removing it and watching a controlled period of data would show a real drop in revenue per visitor. If you can’t point to that evidence, treat it as Tier 1 or Tier 2 until you can.

A useful habit: review your installed apps list regularly against this framework rather than only when the store feels sluggish. Bloat accumulates gradually, a new app here for a seasonal campaign, a trial there for a feature you meant to test, and it’s easier to catch early than to unwind much further down the track.

Should you fix this yourself or get a developer involved?

Removing unused apps and disabling unnecessary features inside an app’s own settings is safe to do yourself. Editing theme code to conditionally load scripts, or replacing an app’s function with custom code, carries real risk of breaking your storefront if it’s not handled carefully, and is worth bringing in a developer for.

The safe, DIY-able tier: uninstalling apps you’ve confirmed are unused, and turning off optional modules inside an app’s settings panel. Shopify’s app uninstall flow removes most of what an app added automatically, though it’s worth checking theme.liquid afterwards for orphaned script tags, which is a quick check even without development experience.

The tier worth a developer: conditionally loading scripts so they only fire on relevant pages, replacing a heavy app with lighter custom code, or restructuring how multiple apps interact with your theme. This is where genuine speed gains usually live, because it’s the difference between an app costing you load time on one relevant page versus every page on your store, and getting that wrong can break checkout, break tracking, or take down a page entirely.

This is the kind of technical work that sits inside proper conversion rate optimisation: it’s not a redesign, it’s finding the specific, measurable thing costing you conversions and fixing that thing. If you’re also seeing organic traffic underperform alongside slow page speed, it’s worth having both diagnosed together, since Core Web Vitals sit at the intersection of SEO and conversion performance rather than belonging cleanly to one or the other.

Frequently asked questions

How many apps is too many for a Shopify store?

There’s no fixed number that’s automatically too many, what matters is each app’s individual performance cost weighed against its function. A lean, well-scoped store with a longer app list can outperform a poorly-audited store with only a handful of apps installed, if those few apps are heavy, globally loaded, and rarely used. Audit by cost and function rather than by counting apps.

Will removing apps actually improve my Google ranking?

It can, if your current Core Web Vitals scores are being held down by render-blocking app scripts. Google’s ranking systems use Core Web Vitals as one of many ranking signals, so a page speed improvement won’t override weak content or thin product pages, but for stores where app bloat is genuinely dragging down LCP or INP, cutting that weight is a legitimate, measurable lever alongside your broader SEO work.

Do reviews apps and upsell apps always slow down my store?

They add some load, since almost every app does, but many are worth keeping because they’re tied to visible revenue impact on the pages that matter most. The question isn’t whether an app has a cost, nearly all of them do, it’s whether that cost is justified by what the app measurably delivers on the pages where it loads.

What’s the fastest way to check if app bloat is a problem on my store right now?

Run your homepage and a product page through Google PageSpeed Insights and look at your total JavaScript size and render-blocking resources. If your Largest Contentful Paint is above roughly 2.5 seconds (Google’s own threshold for a “good” score) and you’re running more than a handful of apps, bloat is a reasonable first place to look before assuming the problem is your theme, your images, or your hosting.

Should I remove an app even if it’s not slowing my site down much on its own?

If it’s genuinely not being used, yes, unused code is still a liability even at a small size, since it accumulates with every other small, unused thing on the store. The point isn’t any single app in isolation, it’s that several apps each adding a modest cost adds up to a meaningfully slower store, and the ones delivering nothing are the easiest, safest place to start cutting.