Why Shopify apps are slowing your store (and the fix)

Every Shopify app you install injects JavaScript, CSS, or Liquid into your storefront, and most of it loads on every pageview whether the feature is used or not. Ten to fifteen apps routinely add hundreds of kilobytes of render-blocking script, which delays Largest Contentful Paint and drags down your Core Web Vitals. The fix is auditing what each app actually costs, cutting the dead weight, and replacing a few heavy apps with native code.

I am a senior Shopify developer based in Delhi, India, and I spend a large share of my performance retainers doing exactly this — pulling apart a slow store, tracing every script back to the app that installed it, and deciding what to keep, cut, or rebuild. This is the audit I run, written out.

Why do Shopify apps slow your store down?

Shopify is fast out of the box. A clean theme on Shopify's global CDN loads quickly almost everywhere. What breaks that is not the platform — it is the layer of third-party code that apps add on top of it.

When you install an app, it hooks into your store in one or more of these ways:

• A <script> tag in theme.liquid that loads the app's JavaScript on every single page, whether the feature runs there or not.
• App blocks and app embeds (Online Store 2.0) that inject Liquid and assets into sections or the theme body.
• CSS files the app loads to style its widget, often a full framework's worth for one small element.
• External network calls to the app vendor's servers, each one a fresh DNS lookup, TLS handshake, and round trip.

The problem is rarely one app. It is the accumulation. A reviews app, a currency converter, an upsell app, a wishlist, a cookie banner, a chat widget, three tracking pixels, a countdown timer — each one seems small in isolation. Stacked together, they load megabytes of JavaScript before your product image finishes rendering. And because most of that script is render-blocking or runs on the main thread, the browser stalls while it parses code the shopper never asked for.

Two numbers get hit hardest. Largest Contentful Paint (LCP) — how long until the main content appears — slips because the browser is busy with app JavaScript instead of painting your hero image. Interaction to Next Paint (INP) — how responsive the page feels — degrades because app scripts hog the main thread. Both are Core Web Vitals, both feed Google's ranking signals, and both are exactly what a shopper feels as "this store is sluggish."

If your store is failing Core Web Vitals, the full diagnosis flow is in why your Shopify store is slow. This post is the app-specific slice of that problem.

How much do apps actually cost in page weight?

Here is a realistic picture of what common app categories add to a page. These are typical ranges — a well-built app sits at the low end, a bloated one blows past the high end.

A store running one app from each category can easily carry 500 KB to 1.5 MB of app JavaScript alone, before the theme, images, or fonts. On a fast office connection that feels fine. On a mid-range Android phone over a patchy 4G signal — which is most of the Indian D2C market — it is the difference between a two-second load and a seven-second one.

The pricing side matters too. Most of these apps carry a monthly fee. Here is what a mid-sized store's app stack often looks like against the cost of building the same feature natively once.

App prices shift often — treat these as approximate and check the current listing on the Shopify App Store before you budget. The point is not that apps are always wrong. It is that some features are cheaper, faster, and fully owned when a developer builds them into your theme once. I break down where that line sits in custom Shopify app vs Zapier vs no app.

How do I audit app overhead on my store?

You cannot fix what you have not measured. Here is the exact audit I run before touching anything.

1. Run PageSpeed Insights and read the right numbers. Put your homepage and a product page through PageSpeed Insights. Ignore the single score for now. Look at LCP, INP, and Total Blocking Time, and scroll to "Reduce unused JavaScript" and "Reduce the impact of third-party code." That third-party section is your app bill, itemised.

2. Use the Coverage tab in Chrome DevTools. Open DevTools, hit the Coverage panel, and reload the page. It shows every script and how much of it goes unused. An app that loads 200 KB and uses 12 KB on that page is dead weight you are paying for on every visit.

3. Trace scripts back to apps in the Network tab. Sort network requests by size and look at the domains. App scripts usually load from the vendor's domain or a recognisable CDN path. Match each heavy request to an installed app. Anything you cannot match to an app you still use is a prime suspect for orphaned code.

4. Test with apps toggled off. This is the real test. Duplicate your live theme, disable an app's embed or remove its block in the copy, and re-run PageSpeed on the duplicate. The delta is that app's true cost. Do it one app at a time and you get a ranked list of what each is costing you, in milliseconds.

5. Check for orphaned code from uninstalled apps. Open theme.liquid and your snippets folder and search for script tags and Liquid includes that point to apps no longer in your admin. Older apps hard-coded themselves into theme files and never cleaned up on uninstall. That code still loads. This is one of the most common hidden causes of a slow store — the app is gone, its weight is not.

Work through those five steps and you will have a ranked, evidence-based list: what each app costs, what is unused, and what is orphaned. Now you can cut with confidence instead of guessing. The mobile-specific version of this — testing on real low-end devices and throttled connections — is covered in Shopify mobile speed for low-bandwidth markets.

Which apps should you cut first?

Once you have the ranked list, triage in this order.

• Orphaned code from uninstalled apps. Free wins. This code delivers zero value and pure cost. Delete every dead script tag and snippet.
• Duplicate functionality. Two apps doing similar jobs — two review tools, two popup tools, a page builder plus a separate section app. Pick one, remove the other.
• Heavy apps for trivial features. A 300 KB app to show a trust badge, a countdown timer, or a size chart. These are the clearest candidates to replace with a few lines of theme code.
• Site-wide apps used on one page. A currency converter or upsell script that loads on every page but only matters on the cart or product page. If it cannot be scoped to where it is used, it is a strong candidate to cut or rebuild.
• "Nice to have" apps nobody uses. The wishlist nobody clicks, the quiz that converts at 0.1%. If it is not earning its page weight, it goes.

The apps to keep are the ones doing real, load-bearing work you could not easily rebuild — a serious reviews platform tied to your email flows, a subscriptions engine, your analytics stack. Even then, prefer apps that ship Online Store 2.0 app blocks over older embedded apps. App blocks load only in the section where you place them and remove cleanly from the theme editor. Embedded apps that inject into theme.liquid load site-wide and leave a mess behind.

Cutting apps is often the single fastest performance win available on a Shopify store, and it usually shows up in conversion too — a faster store converts better, which is half of why your store might not be converting in the first place.

When should you replace an app with custom code?

Not every app should die. The decision comes down to four questions.

Is the feature core to your store? If it is central — your reviews, your bundles, your subscription logic — it is worth owning as native code rather than renting from a vendor who can change pricing, break on a theme update, or shut down.

Is the app heavy relative to what it does? A 250 KB bundle for a static size chart is indefensible. A 250 KB bundle for a full subscriptions and billing engine is reasonable. Weigh the page cost against the job.

Are you paying a recurring fee for something buildable once? Trust badges, product tabs, simple upsells, announcement bars, size charts, basic FAQ accordions — these are typically a few hours of theme work. Over two or three years, the app subscription costs more than the one-time build, and you never own the app version.

Do you need it to survive theme changes and stay fast? Native code you control does not break when the vendor pushes an update, and a developer can build it to load only where needed. That is control an app cannot give you.

Here is roughly where the line falls in my work.

A native rebuild of the simple features usually starts at a theme tweak from ₹40,000 (~$475), and it pays for itself twice: once in removed monthly fees, once in the milliseconds you claw back on every pageview. For a store carrying a dozen apps, that reclaimed speed often moves conversion by more than any single design change.

What does a clean app stack look like?

A healthy D2C store on Shopify usually runs six to twelve apps, each earning its keep:

• One reviews platform (kept, because it is load-bearing and tied to email).
• One email/SMS marketing app.
• One analytics or pixel-management app.
• One subscriptions app, if you sell subscriptions.
• One or two genuinely differentiated features specific to your business.
• Everything else — badges, tabs, bars, simple upsells — built into the theme.

That is the target. Not zero apps — that is unrealistic and unnecessary. The goal is that every app on your store is doing work you could not easily replicate, loading only where it is needed, and pulling its weight in revenue. Everything that fails that test is either cut or rebuilt.

The result is a store that loads fast on a mid-range phone, passes Core Web Vitals, and does not carry a stack of monthly fees for features your theme could do itself. That is the standard I hold retainer stores to, and it is almost always achievable with an audit and a few weeks of focused work.

What's next

If your store feels slow and you suspect the app stack, the Shopify developer page lays out how I work — a full app-and-performance audit, a ranked list of what each app costs you, and a fixed quote to cut, scope, or rebuild. You get senior hours end to end, transparent pricing, and named case studies (Mahina's +28% AOV, Bloom's +22% MoM revenue).

Want the audit first? Tell me your store URL, your app list, and where it feels slow at /start, and I will send back an honest read on what is dragging it down and what it would take to fix.

Related reads

• Why your Shopify store is slow (Core Web Vitals fix) — the full performance diagnosis, beyond apps.
• Custom Shopify app vs Zapier vs no app — when to build, when to automate, when to skip.
• Why your Shopify store isn't converting — how speed feeds into conversion.

Sources

• Shopify — online store speed report and score
• web.dev — Core Web Vitals (LCP, INP, CLS)
• Google PageSpeed Insights