How to find which Shopify apps are slowing your store
Most Shopify merchants reach a point where their store feels slower than it used to be, but no single obvious thing changed. The usual culprit: apps.
Each app you install may add JavaScript, tracking pixels, embedded widgets, or other code that runs on your storefront. Individually, none of it feels significant. Cumulatively — across the ten, twenty, or more apps that many mature stores carry — the effect on page speed can be substantial. The challenge is working out which apps are contributing most, so you can make informed decisions rather than removing things at random.
Why apps affect storefront performance
Most Shopify apps have two distinct parts: admin logic that processes webhooks and manages data on the backend, and a storefront component that loads directly on your live shop pages.
The storefront component is where performance risk lives. When a customer visits your store, the browser downloads and executes every storefront script that is enabled — including scripts from apps that have nothing to do with the page the customer is viewing. A live chat widget loads on a product page even if the customer is heading straight to checkout. A loyalty badge loads on collection pages even when the customer is not logged in.
This is not a flaw in any individual app. It is a natural result of how Shopify's app ecosystem works: apps generally cannot know which pages a customer will visit, so most load everywhere by default unless you configure them otherwise.
Signals that apps are the problem
A few patterns point toward app-driven slowdowns rather than other causes:
Interaction to Next Paint (INP) is poor. INP, which replaced First Input Delay as a Core Web Vital in 2024, measures how quickly your page responds to taps and clicks throughout a visit — not just on the first interaction. When many scripts are competing for the browser's main thread, INP degrades even when the page looks fully loaded and ready.
Lab scores have declined without obvious code changes. If your PageSpeed Insights numbers have dropped over several months but you haven't changed your theme significantly, new or updated app scripts are the most common explanation.
Scores vary meaningfully by page type. If product pages score notably worse than blank pages or thank-you pages, something specific to those pages — likely app embeds or widgets — is the contributing factor.
Ghost scripts are still running. When apps are uninstalled from Shopify, their storefront code is not always fully removed. Scripts left behind by removed apps continue loading on every page, paying a performance cost for functionality you no longer use.
Why manual diagnosis is difficult
The most direct way to identify a problem app is to disable apps one at a time, run a speed test after each change, and compare results. For a store with many apps, that process is tedious and the results can be noisy — page speed measurements have natural variability, and disabling an app does not always cleanly remove its storefront code from an active browser session.
It also misses the cumulative picture. The question you want to answer is not just "does this app slow things down" but "which apps account for most of my total script weight?" Those two questions can have different answers.
What app-impact analysis tells you
A more systematic approach measures the contribution of each app's scripts directly. The key signal is how much script execution time each app accounts for on a typical page load.
Some apps will register near zero — a small configuration snippet or a single lightweight network request. Others may account for a meaningful share of the main thread's time on every page. And some apps that you have already uninstalled may still have scripts running, invisible unless you specifically look for them.
That last category — code from removed apps — is worth prioritising. It adds load time without providing any feature in return, which makes it purely wasteful and worth cleaning up as soon as it is identified.
How to act on the findings
Once you have a breakdown of which apps are affecting performance, the options are practical and manageable.
Remove apps you no longer use. If an app you are not actively using has a meaningful storefront footprint, uninstalling it — and verifying that its scripts are actually gone afterward — is the cleanest fix.
Restrict where scripts load. Many apps allow you to limit their storefront component to specific page types. A pop-up app probably does not need to run on every product and collection page. Checking each app's settings for load controls is a useful one-time audit; the default configuration tends to be "load everywhere."
Clean up ghost scripts manually. Scripts left behind by removed apps may require manual cleanup in theme.liquid, app embed blocks, or asset files. This is more involved, but worthwhile when the footprint is large.
Accept some tradeoffs consciously. Not every app with a storefront impact needs to be removed. A live chat widget that meaningfully reduces cart abandonment may be worth the performance cost. The value of understanding the breakdown is making that tradeoff deliberately rather than unknowingly.
Keeping the picture current
App-driven performance is not a one-time audit problem. The picture changes every time you install or remove an app, update your theme, or when an existing app ships an update that grows its storefront footprint.
That is why ongoing tracking matters more than a single measurement. A performance profile that looked acceptable six months ago may have changed — not because you made a deliberate choice, but because something in the stack updated quietly.
Speedscope includes app-impact analysis as part of its Shopify storefront monitoring. It identifies what is loading on your store's pages — including code from apps that are no longer installed — and breaks down how individual apps contribute to your store's overall performance profile. Combined with continuous Core Web Vitals tracking, you get an ongoing picture rather than isolated readings, so changes in your app stack show up in context.
A reasonable starting point
If you have never audited your app scripts before, the goal does not have to be minimising your app count. It is getting a clear picture of what is running and why, so you can make deliberate decisions.
Start with your app list. For each app, ask: is this still active and used regularly? Is its storefront component actually needed? Would I notice if it were gone?
That audit alone often uncovers apps that can be removed outright, and others that could be restricted to fewer page types with no visible impact to customers. Either change reduces script weight without touching the theme directly.
For stores where apps and themes change regularly, that audit needs to happen more than once. Speedscope is built to make it systematic rather than manual, so you can see how your store's script footprint changes over time rather than discovering problems after they have already affected real shoppers.