The true performance cost of your Shopify app stack

The average mid-sized Shopify store has 26 apps installed. Each one was evaluated on its own merits — does this app do what it says? The question nobody asks during procurement is: what does this app cost in page weight, JavaScript execution time, and render-blocking behaviour?

The performance audit is always the last thing. It should be the first.

How app weight accumulates

Shopify apps inject code into your storefront in a few ways:

Theme app extensions — the recommended modern approach. Code runs through Shopify's rendering pipeline, is subject to performance review during app submission, and loads only on pages that use it.

Script tags — a legacy mechanism where the app adds a JavaScript file to every page load via a script tag. No scoping, no opt-out, loads on every page regardless of whether the feature is in use on that page.

Liquid customisation instructions — "add this snippet to your theme.liquid" instructions in the app setup guide. These become part of your theme's core rendering and are invisible in the app interface — they don't disappear when you pause or uninstall the app.

The problem is that apps installed years ago often used the legacy mechanisms. Their code is running on every page load, even pages where the feature doesn't appear, even if you've stopped actively using the feature, even if you've "uninstalled" the app but didn't clean up the theme modifications.

What a typical audit reveals

When we audit a mid-sized Shopify store that's been running for 3+ years, the pattern is consistent:

Zombie scripts — 3–8 JavaScript files loading on every page for apps that were either removed years ago or never fully cleaned up after uninstall. These range from 10KB to over 200KB each and serve no current purpose.

Duplicate functionality — multiple apps doing overlapping things. A loyalty app, a reviews app, a recommendations app, and a "social proof" app all loading their own analytics tracking separately. Four tracking pixels where one would do.

Layout-shifting widgets — review stars, chat widgets, and promotional banners that load after the initial render and cause Cumulative Layout Shift (CLS) failures. These are often the difference between a passing and failing Core Web Vitals score.

Render-blocking scripts — older apps that load their JavaScript synchronously in the <head>, blocking the browser's HTML parser while they load. Modern script loading uses async or defer. Legacy apps often don't.

The INP problem

Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. INP measures responsiveness: when a user interacts with the page (taps a button, opens a dropdown, selects a size), how long before the page visually responds?

INP failures are disproportionately caused by heavy JavaScript. Every app that loads JavaScript is adding to the main thread work budget. When the main thread is busy executing app code, user interactions have to wait. A store with 15 apps, each loading their own JavaScript bundle, can easily accumulate 3–5 seconds of main thread blocking time — and an INP score in the "needs improvement" or "poor" range as a result.

The relationship between app count and INP is roughly linear up to a point, then exponential as JavaScript competition for the main thread intensifies.

The audit process

Start with a baseline measurement on three page types: the homepage, a collection page, and a PDP.

Use PageSpeed Insights with a UK mobile connection simulation (the default). Note:

LCP (Largest Contentful Paint) — should be under 2.5s
INP — should be under 200ms
CLS — should be under 0.1
Total Blocking Time — proxy for INP problems; should be under 200ms on desktop, 600ms on mobile

Then open Chrome DevTools → Network tab → reload the page. Filter by type: JS. Note every JavaScript file loading, its origin domain, and its size. Map each third-party domain back to which app owns it.

In the Sources panel, check your theme.liquid, checkout.liquid (if applicable), and any snippet files for code that shouldn't be there — look for commented-out snippets, deprecated app code blocks, and references to apps you no longer use.

Making decisions on what to cut

Every app you keep should clear two bars:

Commercial bar: is this app generating measurable revenue or cost reduction that exceeds its fee and its performance cost? For conversion-critical apps (checkout, search, upsell), the ROI is usually clear. For "nice to have" apps that haven't been measured, it usually isn't.

Performance bar: what does this app cost on mobile LCP and INP? If an app adds 300ms to mobile LCP, it needs to be generating enough conversion lift to recover that. A reviews app that adds 200ms to your LCP needs to be converting at a rate that justifies the cost — and most reviews apps, if you measure properly, are not.

The highest-value apps to audit critically:

Chat widgets (almost always loaded eagerly, rarely used by most visitors)
Review widgets (load time vs conversion impact is frequently inverted from what marketers assume)
Loyalty and rewards apps (often loaded on every page even on pages where loyalty UI doesn't appear)
Personalisation and recommendation apps (large bundles with complex initialisation)

The cleanup that makes the real difference

If you find zombie scripts or orphaned theme code:

Disable or uninstall the app properly in the Shopify admin
Search your theme code for the app's snippet references, script tag injections, and stylesheet links
Remove them manually
Redeploy the theme
Re-run your PageSpeed baseline

The before/after on a thorough cleanup is frequently dramatic: 30–50% improvement in Total Blocking Time is common on stores that haven't been audited in two years. That translates directly to INP improvement and, over time, rankings impact.

Performance isn't a one-time audit. App stacks evolve. Set a quarterly baseline measurement and review app additions through a performance lens before they go live, not after.