Almost every slow Shopify store I’ve ever audited had the same root cause, and it’s not the theme. It’s apps. Specifically, it’s the slow accumulation of apps over months and years, each one adding a little weight, until the store that felt snappy at launch now takes five seconds to show a product image on a phone. Nobody decided to make the store slow. It happened one reasonable-sounding install at a time.<\/p>\n
If your store is sluggish and you’re not sure why, this is almost certainly where to look first. This is how apps do the damage, and a practical process for cleaning it up without breaking anything.<\/p>\n
To understand the problem, you need to know what an app actually does to your store when it adds front-end functionality. Many apps inject their own JavaScript and CSS into your pages so they can render their widgets \u2014 a reviews carousel, an upsell popup, a currency switcher, a back-in-stock button. That code has to download, parse, and run in your shopper’s browser, on top of everything your theme is already doing.<\/p>\n
One app doing this is usually fine. The trouble is cumulative. Install fifteen apps that each add a couple of scripts, and your shopper’s browser is now downloading and executing dozens of extra files before the page becomes usable. Worse, a lot of these scripts load from third-party servers you don’t control, so you’re at the mercy of their speed and uptime too. A single slow third-party script can hold up your entire page.<\/p>\n
Then there’s the silent killer: apps you removed but didn’t fully clean up. Some apps leave behind code snippets in your theme even after you uninstall them \u2014 orphaned scripts that do nothing useful but still load on every page. It’s common to find a store carrying the residue of apps it stopped using a year ago.<\/p>\n
Speed isn’t one number; it’s a few distinct experiences, and apps degrade each of them differently. Understanding which is which tells you what to fix.<\/p>\n
App scripts hurt interactivity<\/strong> (the INP metric) most directly. Every bit of JavaScript an app adds is more work for the browser’s main thread, and when that thread is busy running app code, it can’t respond promptly when a shopper taps a button. A store stuffed with app scripts feels laggy \u2014 you tap “add to cart” and there’s a beat before anything happens. That beat is app JavaScript hogging the processor.<\/p>\n Apps that inject content after the page loads hurt visual stability<\/strong> (CLS). A popup that appears, a banner that loads late, a reviews widget that pushes content down as it renders \u2014 each shifts the layout and makes the page jump, which is both annoying and a ranking negative.<\/p>\n And heavy apps that block rendering hurt loading speed<\/strong> (LCP), delaying the moment your main content appears. If an app’s script is render-blocking, the browser has to deal with it before it can paint the page your customer came to see.<\/p>\n Before you start uninstalling things at random, diagnose. Guessing wastes effort and risks removing something that’s actually pulling its weight.<\/p>\n Start with a tool that breaks down what’s loading: PageSpeed Insights, or the browser’s built-in DevTools. Run your homepage and, more importantly, a product page \u2014 that’s where shoppers spend time and where many apps pile on. Look at the breakdown of what’s downloading and what’s consuming the most processing time. Third-party scripts will usually be named in a way you can trace back to the app that added them.<\/p>\n A revealing exercise: duplicate your theme to a development copy, then disable apps one at a time (or in groups) and re-measure. The change in score tells you exactly what each app is costing you. It’s tedious, but it turns a vague “the store is slow” into a ranked list of specific culprits with specific price tags. That list is gold, because it lets you make informed trade-offs instead of emotional ones.<\/p>\n Once you know what’s costing you, work through this in order.<\/p>\n Remove what you don’t need.<\/strong> This is the highest-leverage step and the one people resist most, because every app got installed for a reason that felt good at the time. Be ruthless. For each app, ask whether it’s earning its keep \u2014 driving revenue or saving real time \u2014 or whether it’s a feature you tried once and forgot. The reviews app you actually use stays. The three abandoned experiments go.<\/p>\n Clean up the residue.<\/strong> After uninstalling, check your theme for leftover code from apps you removed. This often needs a developer who can read the theme files and safely remove orphaned snippets without breaking what’s left. It’s one of the most common quick wins in a speed audit: deleting code that does nothing but slow the store.<\/p>\n Consolidate overlapping apps.<\/strong> Stores often run multiple apps that do similar things, each adding its own weight. If two apps overlap, keep the better one. And consider whether several subscription apps could be replaced by one well-chosen tool \u2014 or, for larger stores, by a single custom solution that does exactly what you need without the bloat of a general-purpose app.<\/p>\n Defer what’s non-critical.<\/strong> Not every app needs to load the instant the page opens. A developer can defer scripts that aren’t essential to the initial view so they load after the important content is already on screen. The reviews widget at the bottom of the page, for example, doesn’t need to compete with your hero image for the browser’s attention.<\/p>\n Replace heavy apps with lighter or native options.<\/strong> Sometimes the same job can be done by a lighter app, or built directly into the theme without an app at all. A simple feature implemented natively in your theme is almost always faster than the same feature delivered as a third-party widget.<\/p>\n Cleaning up once is satisfying, but stores drift back toward bloat unless you build habits to prevent it. The accumulation is gradual and invisible until it’s a problem again.<\/p>\n Adopt a simple rule: every app install is a decision with a cost, not a free experiment. Before adding one, ask whether the value clearly exceeds the speed and subscription tax. When you do install something, test your store’s speed before and after so you know what it cost. And when you trial an app and decide against it, uninstall it properly and check for leftover code \u2014 don’t let it linger.<\/p>\n Schedule a periodic app audit, maybe quarterly. Review what’s installed, confirm each app is still earning its place, and remove the ones that aren’t. Pair it with a quick speed check. Treating app hygiene as routine maintenance, like checking inventory, keeps the problem from ever getting bad enough to need a major intervention.<\/p>\n A lot of this you can do yourself \u2014 uninstalling unused apps especially. But cleaning up leftover code, deferring scripts safely, and replacing apps with native theme features are developer tasks, because a wrong move in the theme files can break the store. If you’ve done the obvious removals and the store is still slow, or you’re not comfortable editing theme code, that’s the point to bring in someone who does this professionally. A focused speed audit and clean-up is one of the better-value pieces of development work there is, because it directly improves both conversion and rankings.<\/p>\n To make this concrete, here’s how a speed audit focused on apps actually runs, so you can either do a version yourself or know what to expect when someone does it for you.<\/p>\n It starts with a baseline measurement of the pages that matter \u2014 the homepage, a representative collection page, and a product page \u2014 using both PageSpeed Insights (which shows lab scores plus real-user field data where available) and the browser’s DevTools (which shows exactly what’s loading and how long each thing takes). The product page usually tells the most damning story, because that’s where reviews widgets, upsell apps, and trust-badge tools tend to pile up.<\/p>\n Next comes attribution: working through the list of scripts and identifying which app each one belongs to. Third-party scripts usually load from a recognizable domain, so you can trace a slow or heavy file back to the app that added it. This turns “the store is slow” into “these four apps account for most of the JavaScript and most of the main-thread time,” which is a list you can act on.<\/p>\n Then comes the controlled test that makes the whole exercise rigorous: duplicate the live theme to a development copy, disable apps one at a time or in small groups, and re-measure after each change. The score difference is the price tag for each app. Now you’re not guessing or removing things on a hunch \u2014 you have a ranked list of what each app costs you in speed, which lets you weigh that cost against the value the app provides. An app that adds noticeable load time but drives real revenue might stay; one that adds the same load for a feature nobody uses is an easy cut.<\/p>\n Finally, the clean-up: removing the unused, deleting leftover code from previously uninstalled apps, consolidating overlapping tools, deferring the non-critical, and replacing heavy apps with lighter or native alternatives \u2014 then a final re-measurement to confirm and document the gain. That before-and-after number is also what justifies the work to anyone who needs convincing.<\/p>\n<\/span>Finding the worst offenders<\/span><\/h2>\n
<\/span>The clean-up process<\/span><\/h2>\n
<\/span>Preventing the slide back into slowness<\/span><\/h2>\n
<\/span>When to bring in help<\/span><\/h2>\n
<\/span>A real audit, step by step<\/span><\/h2>\n