Do Shopify apps slow down your store
Yes, most of them do, and the cost is rarely visible on the app listing. A Shopify app embed injects JavaScript into every page it runs on, whether or not the shopper interacts with the feature. Install eight apps and you are shipping eight scripts, eight sets of styles and eight third-party connections before your first product image finishes loading.
The honest version is more nuanced. An app is not slow because it is an app. It is slow because it arrives late, from a domain the browser has never spoken to, and then rewrites part of the page after the shopper can already see it. That is what produces the jump you feel on a bloated storefront: content shifting under your thumb as three widgets fight for the same space.
The question is never whether to use apps. It is which features deserve to be apps at all.
The rule we use: does it need to think
A feature belongs in the theme when its behaviour is fixed and known at build time. A video block, a routine builder, a size chart, a trust bar, a comparison table. None of these need to make a decision at runtime. They need to render, quickly, and get out of the way. Writing them into the theme means they ship as part of the page rather than arriving after it.
A feature belongs in an app when it needs state, rules or a dashboard the merchant will change without a developer. Cart logic that applies gift thresholds and quantity breaks needs to think, and it needs a merchant to reconfigure it on a Tuesday afternoon without opening a code editor. That is a good app. So is a quiz whose questions change with the catalog, or a bundle engine whose offers rotate by season.
Get this split wrong in the other direction and you pay a different price. Hard-coding a discount ladder into Liquid feels fast until the merchant wants to change it and cannot.
What this looked like on a real rebuild
On the Jenpharm rebuild we took this literally. Video, the routine merchandising and the trust modules went into the theme, because none of them needed to make decisions. The cart, the bundle logic and the product quiz stayed as apps, because all three needed rules a merchant would want to change.
The result was a storefront where the heavy visual content was part of the initial render and only the genuinely dynamic features loaded separately. Speed was the win underneath the rest, and it came from keeping weight off the page rather than from any single optimization.
In the first twenty four hours after launch, average order value rose 15 percent and conversion rose 10 percent. Those are early figures from a small window, not a settled measurement, and we would rather say that plainly than round them into something they are not.
How to audit what your apps are actually costing
Open your storefront in an incognito window with the network tab recording. Sort by domain rather than by size. Every third-party host in that list is a connection the browser has to open, negotiate and trust before it can use anything that arrives on it. On a typical Shopify store carrying a dozen apps, that list runs past forty domains.
Now disable one app at a time and reload. Watch the number of requests, not just the total page weight. A 40KB script that blocks rendering hurts more than a 400KB image that loads lazily. If disabling an app changes nothing you can see, that app is a candidate for removal or for being rebuilt into the theme.
The apps worth keeping will justify themselves. Ours are built to: Drawer Cart earns its script by turning the cart into a second sale rather than a dead end. If an app cannot make that case, it is rent you are paying in load time.
When rebuilding into the theme is worth it
Rebuilding a feature into the theme costs developer time once and saves load time on every session afterwards. That trade favours the theme when three things are true: the feature is used on high-traffic pages, its behaviour is stable, and the app version is visibly slow.
It favours the app when the feature is genuinely dynamic, when the merchant needs to change it often, or when the app does something you would not want to maintain yourself. Payment, tax, shipping and fraud are obvious examples. Nobody should be writing their own fraud logic to save 30KB.
If you are unsure, measure before you decide. A four week conversion rate optimization sprint will tell you which pages carry the revenue, and it is those pages, not the average, where the weight actually matters. Speed work on a page nobody converts on is a rounding error.
The short answer
Apps are not the problem. Unexamined apps are. Put fixed, visual, always-rendered features in the theme where they load as part of the page. Keep rules, state and anything a merchant reconfigures in an app where it belongs. Audit the difference every quarter, because app stacks grow quietly.
If you want the split done properly rather than guessed at, bespoke theme development is the service that handles it, and it is the part of a rebuild that pays back longest.