Do Shopify apps slow down your store?
Usually yes, and by more than the app listings admit. Every installed app can inject scripts into your storefront, and each script competes for the same main thread and network budget that renders your pages. A store with twenty apps is running twenty vendors' code on every pageview. The slowdown is measurable, attributable per app, and fixable without deleting everything.
How apps tax the storefront
Most Shopify apps work by injecting JavaScript: widgets, popups, review stars, upsell drawers, chat bubbles. That script loads on page load, parses, executes, and often fetches more data before the page settles. Each app adds to three budgets that all matter: total page weight in kilobytes, number of network requests, and main-thread execution time in milliseconds.
The main thread is the binding constraint. Browsers do layout, parsing, and script execution on one thread, so a 200-millisecond app script does not just add 200 milliseconds somewhere harmless; it blocks everything else for 200 milliseconds, including rendering. Five apps at 200 milliseconds each is a full second of blocked rendering, which shows up directly in Largest Contentful Paint and Interaction to Next Paint.
Measure before you blame
Do not guess which app is slow; measure. The clean method: run a speed test on a key template with all apps enabled, then disable one app and test again. The delta is that app's cost. Repeat for each app. It is tedious, but it produces a ranked list of actual costs instead of vibes, and the ranking almost always surprises: the app everyone suspects is often innocent, and a quiet utility widget is often the hog.
Use the same conditions for every run: same template, same device profile, same throttling, multiple runs averaged. Single-run speed tests are noisy enough to invert a ranking. Three runs per configuration is the minimum for a comparison you can act on.
The usual suspects
Review widgets are the classic offender. They load on product pages, fetch review data from the vendor's servers, render stars and carousels, and often do it with blocking scripts. Chat widgets are next: they load site-wide, including on pages where nobody ever opens chat, and they keep a persistent connection warm. Popups and spin-to-win apps load heavy animation libraries for a component most visitors dismiss in a second.
Upsell and cross-sell apps deserve scrutiny because they inject into the highest-value pages: product, cart, and checkout-adjacent flows. An upsell script that costs 300 milliseconds on the product page is taxing every purchase decision. If the upsell revenue does not clearly exceed the conversion cost of the slowdown, the app is a net loss wearing a revenue dashboard.
Containment rules that work
First, scope scripts to the pages that need them. An app whose widget only appears on product pages has no business loading its script on the homepage, the blog, and the cart. Many apps offer script placement settings; for the rest, conditional loading in the theme can restrict execution by template. Site-wide scripts should be the exception, not the default.
Second, defer what you can. Scripts that do not affect above-the-fold content should load deferred or async, never render-blocking. Third, set a budget: decide the maximum total app-script cost you will tolerate, in milliseconds of main-thread time, and make every new app earn its place against the budget. Apps get installed for one campaign and stay for years; the budget forces the re-evaluation.
The audit cadence
Run the per-app measurement twice a year and after every major app install or theme change. App vendors ship updates that silently add weight, and a widget that cost 80 milliseconds in January can cost 300 by September. Keep the ranked list somewhere the team can see it, and tie it to the renewal calendar: the slowest apps should have to justify themselves at every renewal, with numbers, not testimonials.
The goal is not zero apps. Apps do real work: reviews, loyalty, subscriptions, and support chat all earn their keep on many stores. The goal is priced apps: every app with a measured cost, a measured benefit, and an owner who can say which pages it runs on and why. A store with fifteen measured apps will outperform a store with five mystery ones.
Frequently asked questions
How much do Shopify apps actually slow a store down?
It varies from negligible to several seconds of added load and interaction delay, depending on what the app injects into the storefront. Back office only apps cost nothing. Storefront scripts, especially several stacked together, are where the measurable damage concentrates.
How do I measure an app speed impact honestly?
Test the same page repeatedly with the app enabled and disabled on a duplicate theme, and compare medians rather than single runs. Single speed tests swing wildly. A pattern across five or more runs per state is the minimum evidence worth acting on.
Should I remove apps just to be safe?
Remove apps that show real cost and no measurable value, and leave earning apps alone even if they cost some speed. The audit question is what each app returns for what it costs, not whether the store can reach zero third party code.