How to Audit Your Shopify App Stack in 30 Minutes

Most Shopify stores don't have an app strategy. They have an app history, a record of every problem that needed a quick fix, every feature a vendor demo'd convincingly, every integration a previous agency installed and never revisited. Add those up across three or four years, and you end up with 25, 35, sometimes 50 apps installed, each one loading code your customers didn't ask for.

The frustrating part is that you already know something is wrong. Your store feels slow. PageSpeed scores have been slipping. Someone ran a Lighthouse audit and the numbers look bad. But nobody can agree on which apps are actually responsible, because nobody has looked at what the apps are doing to the live storefront.

This is a 30-minute audit that tells you exactly that. You don't need a developer. You don't need a paid tool. You need Chrome DevTools, access to your admin, and a spreadsheet to take notes.

Here's how it works.

What does a Shopify app actually load on your storefront?

The number visible in your Shopify admin, "34 apps installed," isn't the number that matters for performance. The number that matters is how many of those apps inject JavaScript, CSS, or tracking pixels onto your live storefront pages.

An app you use daily to manage wholesale pricing might load 280KB of JavaScript on your home page, your collection pages, your product pages, and your cart. Even though it only does anything functional when a logged-in wholesale customer views a product. That script is running on every page visit, for every visitor, regardless of whether they're a wholesale customer or a first-time browser arriving from an ad.

That's how app bloat actually works. It's not about how many apps you have in your admin. It's about how much code those apps execute on every page load, and whether that code is earning its place.

Most of that JavaScript overhead isn't coming from your theme. It's app code, and web.dev's guidance on third-party JavaScript identifies it as the primary source of main-thread blocking and delayed interactivity on ecommerce stores.

Why most app audits miss what's actually happening

When most ecommerce teams do an "app audit," they look at the list in their Shopify admin, identify anything they haven't touched recently, and delete it. That's better than nothing. It's also not sufficient.

Two things go wrong with that approach.

The first problem is scope. An app you actively use every day can still be loading hundreds of kilobytes of JavaScript on pages where it provides no value. Many apps are configured to load globally unless scoped; their scripts execute on every page regardless of whether that page has any relevant app functionality. A review widget that only needs to fire on product detail pages often loads on collection pages, the cart, blog posts, and the homepage too. The app is "active" and "in use" but 80% of its page load impact is wasted.

The second problem is ghost code. Uninstalling an app through the Shopify admin removes it from your billing and your admin panel. It doesn't necessarily remove the code snippets the app installed in your theme. Shopify automatically removes legacy ScriptTag resources on uninstall, but depending on how the app integrated with your theme, other edits, {% render %} tags, <script> blocks referencing the app's CDN, CSS <link> tags, may stay in your theme files after uninstall. Cleanup quality varies by app implementation.

That code keeps executing. If the app's CDN is still live, those requests complete. If the app has shut down or changed domains (common with acquired or discontinued apps), those requests fail, adding latency to every page load without delivering any resource.

On one Consumer Electronics Retailer engagement, removing ghost code from previously uninstalled apps eliminated 194 HTTP requests in a single pass. That wasn't from active apps. That was from cleanup alone.

How to run the 30-minute audit

You need two things: Chrome (incognito window) and your Shopify admin. The audit has three parts.

Part 1 — Map what's loading on your storefront (10 minutes)

Open your storefront's homepage in an incognito Chrome window. Right-click anywhere on the page and select Inspect to open DevTools. Go to the Network tab, then reload the page with the tab open.

Once the page loads, filter the requests by JS (the filter bar near the top of the Network tab). You'll see every JavaScript file loaded on that page. Most app scripts are identifiable by their domain or filename, you'll see URLs from static.klaviyo.com, cdn.yotpo.com, loox.io, static.recharge.com, and so on.

For each recognizable app script, note the file size in the Size column and the load time in the Time column. You don't need to be exact. You're building a rough map of what's loading and how heavy it is.

Now switch the filter from JS to All and sort by Size descending. This shows you your heaviest resources. Anything you can't immediately justify, or that's noticeably heavier than everything else, is worth flagging.

Repeat this on two more pages: a collection page and a product page. Then check your cart page. You're looking for scripts that appear on all pages regardless of whether the app's functionality is relevant there.

Part 2 — Cross-reference against your admin (8 minutes)

Open your Shopify admin and go to Apps. You're going to match the script domains you found in Part 1 against your installed app list.

As you go through the scripts, you'll typically find three types:

Recognized, installed: the script belongs to an app you're actively using. Add it to your tracking list.

Unrecognized but installed: you have the app installed but didn't realize it was loading this particular script. Check the app's settings to understand what it's doing.

Unrecognized, not installed: this is ghost code. The domain doesn't match any currently installed app. Copy the domain, search it to confirm which app it belonged to, and add it to your ghost code removal list.

Search any domain you don't immediately recognize. Apps get acquired, rebranded, or renamed. A domain you don't know might belong to a tool you use under a different name now.

Part 3 — Score each app (12 minutes)

For every installed app that's loading frontend code, answer three questions and assign a score.

Does it generate measurable revenue or save measurable operational time? If you can answer this with a specific number —"this drove $X in upsell revenue last quarter" or "this saves us 4 hours a week on customer support volume"—the app earns a Keep. If you can't answer it, the app is on probation.

Is this functionality available natively in Shopify now? Shopify has added native bundles, subscriptions (via Shopify Subscriptions), metafields, combined listings, advanced product filtering, and improved analytics over the past two years. A number of apps that solved real problems in 2022 are solving problems that Shopify now handles out of the box. Apps that fall into this category get scored Cut or at minimum flagged for evaluation.

Does it need to load on every page? If the honest answer is "no, it only needs to run on cart" or "only on product pages," and it's loading globally, score it Scope: keep the app but restrict where its code executes. This often requires a small code change, but it's lower risk than removing the app entirely and it reduces the page weight without changing your functionality.

Your output from Part 3 should be a list of every frontend-loading app scored as Keep, Cut, or Scope.

What you'll typically find

When I open the Network tab on a store with 20+ apps, the same categories show up in the top requests by weight every time: page builders loading on pages they didn't build, loyalty and reviews stacks, live chat, and email capture popups. Those four alone tend to dominate the third-party script list before I've looked at anything else.

Ghost code is the part most teams haven't looked at. Stores older than two years almost always have it. Stores that have migrated themes, from OS 2.0 to a new theme, for example, are especially likely to carry it forward, because the migration process copies the theme files wholesale, including whatever was left behind from three rounds of apps ago.

How to act on what you found

The ghost code removal should happen first. It's the cleanest win: those requests don't come back, they don't require ongoing maintenance, and they don't introduce any risk of breaking active functionality. Plan for a few hours of developer time to find and remove the remnants from your three to five most recently uninstalled apps. Start with any scripts that are failing (returning 404 errors in the Network tab). Those are hurting load time with zero upside.

The Cut items from your scoring come next. Uninstalling is straightforward, but always follow up by checking your theme files manually after each uninstall. Don't assume the uninstall cleaned up the code.

The Scope items take more coordination. Before asking a developer to scope a script, check the app's own documentation or settings. Some apps offer built-in options to control which pages load their scripts. If not, the typical approach is to wrap the app's {% render %} call or <script> tag in a Liquid conditional that checks the current page template.

The Keep items earn their place for now, but they're worth revisiting quarterly. What justified an app six months ago may not justify it today, especially as Shopify continues expanding its native capabilities.

If you run through this audit and the results are messier than you expected, I'm happy to take a look. Sometimes what appears to be an app problem is something deeper in the theme architecture, and sometimes 30 minutes of outside review surfaces things that are hard to see when you're inside the store every day.