Performance

How many Shopify apps is too many?

Widget apps do not slow your store by existing — they slow it by loading JavaScript. How to measure what your app stack really costs, and what to cut first.

Updated 22 August 2026 · 8 min read

Every Shopify performance article opens with the same claim: too many apps will kill your store speed. It is true enough to be useful and vague enough to be useless. Ten well-built apps that install as theme app blocks and render server-side will cost you almost nothing. Three badly built apps that each inject a 90KB bundle into every page will cost you a Lighthouse score and, on mobile, real revenue.

The number of apps is not the metric. The metric is how much JavaScript reaches the browser, and how much of it blocks the main thread before the shopper can interact.

What a widget actually costs

A widget's cost has four parts, and merchants usually only think about the first one.

  • Payload. The kilobytes of JS and CSS downloaded. A countdown timer needs about 15KB of logic. Many ship 60–120KB because they bundle a framework.
  • Requests. Each app is a DNS lookup, a TLS handshake and a round trip. On a 4G connection, the connection setup often costs more than the file.
  • Main-thread time. Parsing and executing JavaScript blocks interaction. This is what Interaction to Next Paint measures, and it is the metric most Shopify stores fail.
  • Layout shift. A bar or badge that renders after first paint and pushes content down is a Cumulative Layout Shift penalty, every page load, forever.

The last two are where the damage is, and neither shows up if you only look at the app's file size.

Measure your own stack in ten minutes

Do not guess and do not trust a vendor's claim that their app is "lightweight". Measure.

  1. Open your live product page in Chrome DevTools, Network tab, with cache disabled and throttling set to Slow 4G.
  2. Sort by Domain. Every domain that is not your store, Shopify's CDN, or your fonts is an app.
  3. Note the transfer size per app domain. Anything over 50KB on a single page is worth questioning.
  4. Switch to the Performance tab, record a page load, and open the Bottom-Up view grouped by URL. This shows main-thread time per script — the number that actually correlates with how slow the page feels.
  5. Run the same product page through PageSpeed Insights and read the field data at the top, not the lab score. Field data is your real shoppers on their real phones.

Now duplicate your theme, uninstall a candidate app on the duplicate, and repeat. The delta is the app's true cost. This is the only measurement that settles an argument.

The removal order

When you need to cut, cut in this order.

First: apps you are not using. Every store has them. An app installed for one BFCM two years ago, still loading on every page. Uninstalling does not always remove the code — see the section on leftovers below.

Second: duplicates. Two apps that both do social proof. A review app and a separate testimonial app. A suite app whose badge module you use plus a dedicated badge app. Pick one.

Third: apps whose job the theme can do. Modern Shopify themes handle sticky headers, image galleries, accordion FAQs, size charts as metafields, and often announcement bars. An app for any of these is pure overhead.

Fourth: the heaviest remaining app with the weakest attributed revenue. By this point you are making a real trade, so make it on data — the app's measured cost against what it demonstrably earns.

The leftovers problem

Uninstalling an app does not reliably remove its code. Apps installed the old way — via script_tag injection or by editing theme.liquid during onboarding — leave orphaned snippets behind that keep firing requests to a service that no longer answers.

After uninstalling anything, check your theme code for leftovers:

  • In the theme editor, open Edit code and search theme.liquid for the app's name or domain.
  • Look through snippets/ for files named after apps you no longer run.
  • Check for <script src> tags pointing at domains you do not recognise.

Apps built as theme app extensions — the app-block model Shopify has pushed since Online Store 2.0 — do not have this problem. They are sandboxed, you place them in the theme editor, and uninstalling removes them cleanly. When two apps are otherwise equal, this is the tiebreaker.

A realistic budget

For a mid-size Shopify store, a defensible target on the product page:

MetricTargetFailing
Third-party JS transferredUnder 150KBOver 400KB
Third-party domains5 or fewer10 or more
Largest Contentful Paint (field, mobile)Under 2.5sOver 4s
Interaction to Next Paint (field)Under 200msOver 500ms
Cumulative Layout ShiftUnder 0.1Over 0.25

If you are inside those numbers, stop optimising and go do merchandising. Speed is a hygiene factor: being fast does not sell products, but being slow stops you selling them.

The consolidation trade

The cleanest way to cut third-party requests is to replace several specialist apps with one suite. One vendor, one script, one bill. That is a genuine performance win and the strongest argument all-in-one apps have.

It is also a lock-in decision. Leaving means rebuilding reviews, badges, upsells and bundles at the same time, and you will be doing it because something has gone wrong rather than because you planned to. Make the trade deliberately: consolidate when speed is the binding constraint, stay specialist when the individual tools are earning enough to justify the overhead.

The one thing not to do is what most stores do by default — install a specialist for every idea, never measure, and discover the cost eighteen months later when mobile conversion has quietly dropped.

More like this, monthly

Widget teardowns with real page-weight measurements. No sponsorships.