Ask this question in the Shopify Community forums and you’ll find a version of the same thread over and over: a merchant with somewhere between 15 and 30 installed apps, a Lighthouse score they’re not happy with, and a genuine uncertainty about which apps are actually the problem. The honest answer nobody wants to hear is that there’s no magic number. A store with eight badly-behaved apps can be slower than a store with twenty well-built ones.
What actually matters isn’t the app count on your Settings > Apps and sales channels page, it’s how much JavaScript, CSS and Liquid code each of those apps is injecting into every page load, whether that code is doing anything useful for the customer in front of it, and whether two or three of your apps are quietly fighting over the same job.
This post walks through how Shopify apps actually affect store speed, a practical method for auditing what’s installed, and a decision framework for what to keep, replace, or cut, the kind of audit worth running every six to twelve months, not just when your speed score finally forces the issue.
How Shopify apps actually affect store speed
Every app you install is, at a technical level, adding code to your storefront. How much it slows you down depends on how that code gets added and how disciplined the developer was about performance. A few mechanisms are worth understanding before you start auditing:
- Theme app extensions and app embeds. Since Shopify moved toward Online Store 2.0, most modern apps add their front-end functionality through app embeds and app blocks, toggled on in the theme editor. This is a cleaner method than the old approach, but an app embed still loads its own JavaScript and CSS on every page, whether or not that feature is actually being used on the page the customer is viewing.
- Additional HTTP requests. Each app typically pulls in its own script file (sometimes several), separate from your theme’s core assets. More requests generally means more time spent establishing connections and waiting on responses, particularly on mobile connections, even when each individual file is small.
- Render-blocking scripts. Some apps load scripts in a way that blocks the browser from rendering the page until that script has finished loading and executing. A poorly built pop-up, reviews widget, or upsell app is a common culprit here, because it needs to run before it can decide whether to show anything.
- Liquid snippet bloat from legacy installs. Older apps, or apps installed and later removed without a clean uninstall, can leave Liquid snippets and script tags behind in your theme code. These don’t show up in your Apps list anymore, but the code can still be sitting in theme.liquid or a template file, quietly loading on every page for a feature nobody uses.
None of this means apps are inherently bad for performance, Shopify’s platform is built to support a large app ecosystem, and plenty of stores run 15+ apps with no noticeable speed problem. The issue is unaudited accumulation: apps installed for a campaign eighteen months ago, trial installs from an old marketing test, or three overlapping tools solving the same problem because nobody checked what was already there.
How to audit your installed apps: a step-by-step method
A proper audit combines what’s currently installed with what’s actually running on your storefront, because those two lists are not always the same.
Step 1: Review what’s installed
Go to Settings > Apps and sales channels in your Shopify admin. This gives you the full list of apps currently connected to your store. For each one, note:
- When it was installed (if you can recall or check billing history)
- What it’s meant to do
- Whether anyone on your team actively uses its admin dashboard
Apps nobody remembers installing, or apps whose purpose nobody can explain in one sentence, are your first audit candidates.
Step 2: Check theme app embeds and blocks
In the theme editor, open the App embeds panel (the small toggle icon in the left-hand sidebar). This shows every app currently injecting code into your live theme via app embeds, including ones that might be doing so silently in the background. Cross-reference this list against Step 1, an app that’s installed but has its embed switched off isn’t contributing to page weight from that mechanism, while an app with its embed switched on but rarely used by customers is a strong candidate for review.
Step 3: Use browser dev tools and Lighthouse to see real impact
This is where you move from “what’s installed” to “what’s actually slow.” Run a Lighthouse report (built into Chrome DevTools, under the Lighthouse tab) on a real product page and your homepage, not just a low-traffic test page. Look specifically at:
- Third-party script requests in the Network tab, sorted by size or load time, this usually surfaces which apps are the heaviest.
- Render-blocking resources, which Lighthouse will flag directly with a list of the offending scripts.
- Total blocking time and Largest Contentful Paint, since a single badly-behaved app script can be responsible for a disproportionate share of both.
Match the domains and script names shown in dev tools back to your app list from Step 1. It’s common to find that two or three apps are responsible for the majority of third-party load time, while the rest are effectively negligible.
Step 4: Check for orphaned theme code
Search your theme code (Online Store > Themes > Edit code) for script tags, snippets, or sections referencing apps you no longer have installed. This is easiest to spot in theme.liquid and any custom sections, since that’s where older app installs most often left a manual snippet behind rather than using the cleaner app embed method. Orphaned code like this contributes to page weight for zero business benefit, since the app itself isn’t even running your feature anymore.
The keep, replace, or cut decision framework
Once you know what’s installed and what’s actually costing you load time, run each app through the same three questions:
- Usage frequency, Is this app doing something on every page (like a reviews widget or a chat launcher), only on specific pages (like a size guide), or only during occasional campaigns (like a holiday pop-up)? Apps running sitewide need a much higher bar for justified performance cost than apps scoped to a handful of pages.
- Overlap with other apps or native Shopify features, Does another installed app already do part or all of this job? Does Shopify’s native functionality (e.g. native product reviews-adjacent metafields, native discount codes, native currency conversion in some plans) already cover it without a third-party app at all?
- Performance cost vs business value, Given what you saw in Lighthouse and dev tools, is this app’s load-time cost proportionate to the revenue or conversion value it demonstrably contributes? An app driving a meaningful share of email signups or upsell revenue can justify more performance cost than one that’s “nice to have.”
Score each app as:
- Keep, clear usage, minimal overlap, performance cost justified by value.
- Replace, the job is worth doing, but a lighter-weight app (or a native Shopify feature) can do it with less overhead.
- Cut, low or no usage, overlaps with something else, or costs more in load time than it returns in value.
Work through this list app by app rather than trying to judge the whole stack at once, it’s much easier to make a clear call on one app at a time than to eyeball fifteen simultaneously.
This is exactly the kind of methodical audit that’s worth pairing with a proper technical review if your store is customer-facing and revenue-critical. Nexly’s Shopify performance optimisation service covers this end-to-end, auditing app impact, cleaning up orphaned theme code, and re-testing against Core Web Vitals after changes, rather than guessing which app to cut and hoping the speed score improves.
Common categories where apps overlap unnecessarily
A few categories show up again and again as the source of avoidable overlap:
- Multiple reviews apps. Common after a platform switch or a failed trial of a new tool, the old app’s widget and code sometimes stays live even after a new one is installed, doubling up on script weight for the same feature.
- Multiple pop-up or upsell apps. One app handling exit-intent pop-ups, another handling cart upsells, and a third handling email capture, when a single well-configured tool could often cover two or three of those jobs.
- Overlapping analytics or tracking pixels. Beyond Shopify’s native analytics and GA4, it’s common to find two or three separate marketing apps each injecting their own tracking scripts for largely the same data.
- Redundant currency or country-detection apps on stores that could use Shopify’s native Markets functionality instead, depending on plan.
- Duplicate live chat or support widgets, left over from switching providers without fully removing the old one.
Practical checklist for your next app audit
- List every installed app via Settings > Apps and sales channels
- Cross-check against theme app embeds in the theme editor
- Run Lighthouse on your homepage and a real product page
- Identify the heaviest third-party scripts in the Network tab
- Search theme code for orphaned snippets from uninstalled apps
- Score each app as keep, replace, or cut using usage, overlap and value
- Remove cut apps fully, including any leftover theme code, not just the app itself
- Re-run Lighthouse after changes to confirm measurable improvement
FAQ
How many apps should a Shopify store have?
There’s no fixed ideal number, a well-optimised store can comfortably run 15 or more apps, while a poorly optimised store can be slowed down by five. What matters is whether each app is earning its performance cost through genuine usage and business value, not the raw count on your apps list.
Do uninstalled apps still slow down my store?
Sometimes, yes. If an app was installed before Online Store 2.0 or added Liquid snippets manually rather than through app embeds, uninstalling the app doesn’t always remove that code automatically. It’s worth checking your theme code directly for leftover script tags after any app removal.
Will removing apps definitely improve my Shopify speed score?
Removing genuinely unused or heavy apps usually helps, but the improvement depends on how much load each one was actually contributing. Removing a lightweight, well-built app will barely move the needle, while removing one heavy, render-blocking script can produce a noticeable jump in your Lighthouse score.
Can I just disable an app’s theme embed instead of uninstalling it?
Yes, and this is a useful test step, toggling an app’s embed off in the theme editor stops it injecting code without fully removing the app or its settings, which lets you measure its performance impact before committing to cutting it entirely.
How often should I audit my Shopify app stack?
Every six to twelve months for most stores, or immediately after a busy sales period like a holiday campaign, since that’s when temporary or trial apps most often get added and then forgotten.
Ready for a proper speed audit?
If your app stack has grown faster than anyone’s had time to review it, a structured audit will tell you exactly what’s costing you load time and what’s worth keeping. Book a Shopify audit with Nexly and get a clear, prioritised list of what to fix first.
