How Do You Know Which Shopify Apps Are Actually Slowing Your Store Down?
Most Shopify stores can tell you what apps they have installed. Almost none can tell you what each one costs in page load time. That gap is what an app stack audit closes, and it takes about 30 minutes if you know where to look.
The problem isn't that the data is hard to find. It's that nobody looks at it. Every app you've ever installed left assets on your site: JavaScript, CSS, tracking pixels. Those assets load on every page regardless of whether the app is doing anything useful there. The goal of this process is to surface what's actually loading, put a number on what each item costs, and make removal decisions based on that data instead of guesswork.
Here's how to do it.
Why can't I just check my Shopify admin and count my apps?
Your installed apps list is not a performance inventory. It shows you what has API access to your store. It doesn't show you what's loading in a visitor's browser on every page request.
When you install a Shopify app, it typically injects JavaScript, CSS, and tracking pixels directly into your theme files. Those assets load on every page. Often before your product images. Often blocking the browser from rendering anything else while they execute.
When you uninstall that app, the API access gets revoked. Whether the injected code gets cleaned up depends on the app. Some apps remove their theme modifications on uninstall. Many don't. Shopify's platform doesn't automatically remove code that was written into your theme files. So a store that's tested a dozen apps over three or four years may be loading assets from several of them on every page, even though those apps no longer appear in the admin.
That's why your admin count and your actual performance load are two different numbers.
You can find a full breakdown of how this accumulates in my complete guide to Shopify app bloat.
What does "app bloat" actually cost on a page load?
Each app script is a separate HTTP request. Each request takes time to initiate, download, parse, and execute. When multiple scripts load in sequence (the default behavior unless the app developer explicitly addressed it), each one delays everything that comes after it.
In my experience auditing Shopify stores, third-party app scripts are the most common source of main-thread blocking. More often than theme code. More often than unoptimized images. Each script that runs synchronously before the browser paints anything visible is directly adding to your Time to First Byte and your Interaction to Next Paint score.
I worked with one store where removing unnecessary app scripts eliminated 194 HTTP requests from a single page load. The store hadn't changed a product, updated a theme, or touched a template. Just removed code that had no business being there. That's the scale of what accumulated app decisions can look like on a store that's been running for a few years.
What do most stores get wrong when they try to fix this?
They look at their app list and start optimizing the ones they know about.
They'll spend time reducing Klaviyo's tracking payload, or switching to a lighter chat widget, or compressing the images their review app is loading. That can help at the margins. But it's working around the problem, not through it.
The bigger issues are usually invisible:
Apps you forgot you installed. A store that's been running for four or five years will have gone through product managers, agency relationships, and A/B testing phases. Every tool someone tried left a footprint. Nobody documented what was removed.
Apps that load globally but only function on one page. A cart upsell app loading its entire JavaScript bundle on your homepage has no reason to exist there. It slows down your busiest page for no user benefit.
Code from apps you uninstalled that may still be in your theme. If an app didn't clean up after itself on uninstall, its script tags are still in your theme.liquid and its files are still in your snippets/ directory, running on every page load.
The pattern I see most often: a store cleans up the apps it knows about. The orphaned scripts, zombie tracking pixels, and unused widget libraries don't get touched, and that's usually half the page weight.
How do you run a 30-minute app stack audit?
This isn't a deep technical review. It's a triage pass, enough to surface what you're dealing with and identify the highest-impact items to investigate further.
What you need: Chrome, access to your theme files, and your app subscription list.
Step 1: Run a waterfall report (5 minutes)
Open Chrome and navigate to your storefront homepage. Open DevTools (F12 or right-click → Inspect), go to the Network tab, and reload the page.
Sort the requests by domain. You're looking for any domain that isn't your Shopify CDN (cdn.shopify.com) or a core platform service. Every third-party domain is a separate server your visitor's browser had to contact before your page finished loading.
Look at the waterfall column. The horizontal bars showing when each request started and how long it took. Requests that start late and run long are your candidates. Scripts with long pink bars are blocking the main thread while they execute.
Make a list of every third-party domain you see. Don't filter yet. Just document.
Step 2: Cross-reference against your installed apps (5 minutes)
Go to your Shopify admin → Apps. For each domain you captured in Step 1, try to match it to an installed app. Common patterns: cdn.klaviyo.com → Klaviyo, api.yotpo.com → Yotpo, d.rechargeapps.com → Recharge, static.rebuysegment.com → Rebuy.
Some domains won't match anything in your installed list. Write those down separately. They're candidates for leftover code from previously uninstalled apps.
Step 3: Check your theme files for orphaned code (10 minutes)
Go to Online Store → Themes → your live theme → Edit Code.
Open theme.liquid (in the Layout folder). Search for <script tags. For each one, look at the src attribute. Does that domain appear in your installed apps list?
Do the same for snippets/, look for any files with app names in the filename (e.g., klaviyo-consent.liquid, loox-reviews.liquid, recharge-cart.liquid). If the app is uninstalled and the file has no references to active functionality, it's a candidate for removal.
You won't remove anything yet. You're just inventorying.
Step 4: Check your app spend (5 minutes)
Go to Shopify admin → Settings → Billing → App charges. Look at your recurring charges for the past 30 days. Compare that list to your installed apps.
Are you paying for anything you haven't actively used in three months? Flag it. Cost is a secondary concern in an audit; performance is primary, but redundant spend alongside redundant code is worth noting in the same pass.
Step 5: Prioritize by page weight and page type (5 minutes)
Back in your Network tab waterfall, look at:
- Transfer size — how many KB each app's assets add to your page weight
- Blocking time — scripts that run before the browser can paint anything visible
- Which pages they load on — a loyalty widget loading on your collection pages has a different impact than the same widget loading only on your account page
Apps loading on your homepage, collection pages, and product pages deserve the most scrutiny. Those are your highest-traffic pages. A script adding 300ms to your product page affects every shopper who browses your catalog.
What are the most common things you'll find?
In my experience across store audits:
Review app scripts loading on pages without reviews. Apps like Yotpo, Judge.me, and Loox typically load their JavaScript globally. If your homepage doesn't display reviews, there's no reason for their scripts to load there.
Multiple analytics tools tracking the same events. A store that's been through an agency relationship or two often has Google Analytics, a Shopify app analytics tracker, and a third-party attribution tool all firing simultaneously. Two of them are usually redundant.
A live chat widget loading on mobile. If your mobile chat engagement is low, you're paying the full performance cost of loading the chat library for minimal return.
Script tags referencing domains that haven't been active in over a year. I've opened theme files for stores that were confident they'd cleaned up after their old tools and found references to apps that had been uninstalled twelve to eighteen months earlier.
How do you decide what to remove?
Don't remove anything during the audit. The audit tells you what's there. The removal decision is separate.
For each app you identify, ask:
- Is this app still doing a job I can measure? Not "is this doing something". Is there a metric that would move if I removed it?
- Is this job something Shopify can handle natively without a third-party app? Shopify Functions, Metaobjects, and native subscription APIs now cover territory that required paid apps two or three years ago. Worth checking before renewing.
- If I removed this app and its code, what breaks? Can I test that on a duplicate theme before touching the live store?
The question to avoid: "when did we install this?" Recency doesn't tell you whether something is working. Measurement does.
What about code I find from apps I've already uninstalled?
Duplicate your live theme before touching anything, and remove one item at a time.
Work only in the duplicate. When you've removed a script or snippet, test that theme using the preview link, not by publishing it, and verify nothing breaks.
Items most likely to cause problems if removed incorrectly: app blocks in your sections, Liquid tags that call a snippet that no longer exists, and cart functionality tied to a checkout extension.
Items that almost never cause problems when removed: standalone <script> tags pointing to domains you can't match to any installed app, CSS files from apps you stopped using, and tracking pixels for tools you cancelled.
If you're not comfortable editing theme files directly, document what you found and hand it off to a developer with a clear brief: "These script tags don't match any installed app. Remove them from a duplicate theme and verify nothing breaks before we touch the live theme."
How do you know when you've made a difference?
Run your PageSpeed Insights report before you start: homepage, one collection page, one product page. Record the scores. Run it again after your cleanup.
The metric that matters most for this type of work is Total Blocking Time (TBT). Google defines it as the sum of all long tasks that delay interactivity, and it's a lab metric that directly predicts INP (Interaction to Next Paint) performance, now a Core Web Vital. Google's threshold for a good INP is 200 milliseconds or less. If you've removed scripts that were blocking the main thread, TBT drops and INP improves.
Don't expect identical results across every store. A store with five apps and clean code will see modest movement. A store carrying assets from a dozen previous installs across several years of decisions has more room to move.
If you've gone through this process and found more than you expected, more domains loading, more orphaned code, more scripts from tools you thought were gone. I'm happy to take a look at what you're working with and tell you where I'd focus first.