The Shopify App Audit We Run Before Touching a Single Line of Code

Every store we inherit arrives with the same disease. Twenty four apps installed, fourteen of them last touched by the founder at 2am in 2023, and a PageSpeed score somewhere between 18 and 34. Nobody can tell you which apps are actually making money.

Before we write a single line of Liquid, before we crack open the theme, before we even talk about CRO, we run an app audit. Not a glance at the admin page. A forensic, script by script evaluation that ends with a scored spreadsheet and a named kill list. This article is the method we use. Run it yourself, or pay us a fixed fee to do it cold.

Most guides on this topic stop at "uninstall the ones you don't use." That advice has cost merchants millions in unexplained conversion drops, because the app you never opened was the one quietly firing the Meta pixel that your ads manager depends on. What follows is harder, slower, and correct.

Why App Bloat Is a Bigger Problem in 2026 Than It Was in 2022

The Hyperspeed team audited 1,166 live Shopify stores last year. The average PageSpeed score came in at 30. Third party scripts accounted for 62 percent of all JavaScript on those sites. The average install count sat between 15 and 25 apps, which on a typical store translates to 500KB to 2MB of third party JavaScript firing on every page load.

The platform has also changed underneath those apps. As of February 2025, Shopify blocked the ScriptTag API on Thank You and Order Status pages. Non Plus ScriptTags are fully deprecated on August 26, 2026. Shopify Scripts, the old Ruby based discount engine, stops executing on June 30, 2026. A meaningful number of apps in your admin are loading code via mechanisms Shopify is actively shutting down. Some will silently break. Others will be replaced by heavier web pixel extensions or theme app embeds that bundle more dependencies than the original. If you have not audited in the last nine months, your performance profile is already drifting.

The real reason app bloat is worse than it used to be is that the Shopify app ecosystem competes on feature richness, not on kilobytes. A review app from 2020 was 80KB gzipped. The 2026 version of the same app is 340KB because it now ships AI summarisation, social proof widgets, and a video module the merchant never turned on. You upgraded automatically. Nobody sent you the release notes.

The Four Axis Scoring Rubric

We score every installed app on four axes, each from one to five, giving a total out of twenty. Anything under ten goes on the kill list. Ten to fourteen is optimise or replace. Fifteen to twenty stays. The axes are deliberately not equal weighted in the founder's head, because they trade against each other, and the rubric forces you to face that trade.

The first axis is JavaScript weight, measured as gzipped transfer size on the storefront, not as the uncompressed bundle the app vendor quotes on their marketing page. A score of five means under 20KB on the wire. A score of three means 50 to 100KB. A score of one means over 200KB, which, for reference, is the territory Intercom, Yotpo Reviews, and most full fat chat widgets occupy by default.

The second axis is render blocking behaviour, and this is where most founders get surprised. A heavy script that lazy loads on user interaction scores a five. A heavy script that loads async, after parse, scores a four. A script that is deferred but runs on DOMContentLoaded scores a three. A script injected by a theme app embed that runs in the head without async scores a two. A script that blocks the HTML parser and forces synchronous execution, which is more common than it should be in apps that rely on cookie reading before the page renders, scores a one. A 400KB app that loads on click is forgivable. A 30KB app that blocks the parser is not.

The third axis is business value, and it is the one founders refuse to answer honestly. A five means the app is directly tied to attributed revenue you can point at in Shopify Analytics or your ad platform. Klaviyo, a paid cart recovery flow with measurable recovered revenue, a subscription app that 18 percent of your customers use. A three means operational necessity without direct revenue attribution, a shipping rules app or a fraud filter. A one means decorative or unknown. If you cannot tell us what the app earned you last quarter, it scores a one, regardless of how much you like the founder of the company that makes it.

The fourth axis is replaceability. A five means the app is genuinely unique, solving a hard problem nobody else solves, integrated into workflows that would take weeks to rebuild. A three means there is a lighter competitor you could swap to in a day. A one means you could replace it with a native Shopify feature, a Liquid snippet, or a theme setting you already paid for. Most cookie consent banners are a one. Most pop up apps are a two. Most native language translation apps, when the merchant only supports two languages, are a one because Shopify Markets does it for free.

A concrete example. A merchant we took over last quarter was running a social proof app at 210KB, render blocking on all pages, driving 0.3 percent of attributed sessions, replaceable in an afternoon with a Liquid snippet pulling from the orders API. Scores, in order, one, one, one, one. Total four. Kill.

The Exact DevTools Workflow

The admin page gives you a list of apps. It does not tell you which apps are loading on the storefront, what they weigh, or whether they block. For that you need Chrome DevTools, specifically three tabs most founders never open.

Start on the Network tab with an incognito window and cache disabled. Load the homepage, a collection page, a product page, and the cart, reloading between each. Filter by JS and sort by transfer size descending. Group by domain, which is the option hidden in the settings cog at the top right of the panel. You are looking for scripts served from domains that are not your storefront and not cdn.shopify.com. Those are apps. Write down the domain, the file name, and the transfer size. This list, cross referenced against your installed apps, is your ground truth. You will find apps loading that you forgot existed, and occasionally you will find apps that are not listed in your admin because their ScriptTag registration outlived an uninstall.

Next, open the Coverage tab, which lives under the three dot menu in DevTools under More Tools, Coverage. Reload the page with recording on, then interact with it briefly, add to cart, open a drawer, scroll. Coverage reports, for each script, how many bytes were downloaded and how many were actually executed. Any app showing 80 percent or more unused bytes is paying rent for code that never runs on this store. That is a negotiation lever with the app vendor, a case for switching plans, or a case for removal. We have found 1.2MB of unused JavaScript on a single product page that way, loaded by seven apps.

The third tab is the Performance tab, run a recording of a page load, then switch the summary view to Bottom Up and group by URL. This surfaces CPU time by script origin. A chat widget that weighs only 90KB can still eat 400ms of main thread time on a mid range Android device, and the only way you see that is on the Performance tab with CPU throttling set to four times slowdown. Run every audit at four times CPU throttle and Slow 4G network throttle. Desktop numbers lie. Shopify's own guidance is that Liquid render should stay under 200ms, and it is mostly achievable, but app JavaScript parse and execute is what will push a real user's LCP past three seconds.

The fourth step, and the one almost no audit guide covers, is request blocking. In the Network tab, right click any request and choose Block Request Domain. You can now simulate the removal of an app without actually uninstalling it, then reload and measure the page in Lighthouse. We have a standard checklist, block every app domain in turn, record the PageSpeed delta, and log which apps move the score by more than five points, which is the threshold above which removal is worth the conversation.

Staging and Rollback, The Protocol That Saves Revenue

The number of Shopify agencies that test app removal on a live storefront is embarrassing. We do not. Here is the protocol, and if you run it even once you will find hidden dependencies you would have shipped straight into production.

Step one, duplicate the live theme, label it with the date and the words "audit base." This is your rollback point, untouched. If anything goes sideways, you publish this theme in thirty seconds and you are back to baseline. We have had to do it twice in five years. Both times the thirty seconds mattered.

Step two, duplicate the audit base again, label it "audit test." Publish this to a password protected staging environment using Shopify's Preview link, which lets real users hit the test theme without affecting anyone else. Turn on customer privacy properly, because app embed and web pixel code paths respect consent flags and you will get false performance wins if you test with consent rejected.

Step three, take a revenue snapshot. Last seven days of conversion rate, add to cart rate, checkout initiation rate, and PDP to cart rate, segmented by device. These are your control numbers. A 1.2 percent conversion rate drop looks like noise on day one and a fired agency on day five.

Step four, disable one app at a time, not in groups. When you disable in groups and conversion drops, you do not know which app caused the drop. Disable, measure performance, watch conversion data for 24 to 72 hours depending on traffic, then move to the next. On stores doing 500 plus sessions a day, 24 hours is usually enough signal. Below that, batch conservatively.

Step five, before you publish the cleaned theme to production, do a full Preview pass with the client over a shared screen. The number of times a founder has said "wait, that banner was important, we use it for launches" at step five is the reason step five exists. After go live, keep the audit base theme in the library for 30 days, then archive it.

The Contrarian Part, Speed Apps That Make Your Store Slower

There is a category of Shopify app we have started refusing to install on client stores, and it is the one that markets itself as a speed booster. Lazy loading apps, image optimisation apps, "AI powered" performance apps. The reason is simple. Most of them inject their own 40 to 80KB of JavaScript to implement behaviour the browser, the theme, or Shopify's native image pipeline already does natively and faster.

Native loading equals lazy on img tags, added by any half competent theme after 2020, costs zero bytes. A speed app doing the same job costs 60KB and executes on every page. Shopify's image CDN already serves responsive, format negotiated, dimension hinted images when you use the image_url filter with width parameters, which is the default in Dawn. A third party image optimisation app that rewrites img tags to its own CDN adds a DNS lookup, a connection setup, and a layer of failure you own but cannot fix.

We have measured this. Nine out of the last twelve "speed" apps we have audited on takeover stores had a net negative impact on LCP and TBT once measured properly on a throttled mobile profile. The audit score for most of them comes out two on weight, two on render blocking, one on business value (because the value claim is speed, which we can now measure as negative), and one on replaceability. Four out of twenty. Kill.

The same principle applies, in lesser form, to review apps that ship schema markup, cookie apps that duplicate functionality in Shopify's Customer Privacy API, and chat apps where actual chat volume is under one percent of sessions. In each case, the test is the same. Measure the script. Measure the business value. Compare to native or to the lightest competitor. Score it honestly.

Where This Leaves You

If you run this audit yourself, budget eight to twelve hours for a store with twenty apps. Budget longer if you have a subscription business, international markets, or a headless front end. At the end you will have a scored spreadsheet, a kill list, an optimise list, and a plan. You will also have the hardest conversation of the engagement, which is the one where the founder has to admit that the app they installed because a competitor uses it is scoring six out of twenty and has to go.

If you would rather we did this for you, the WitsCode Shopify App Audit is a fixed scope engagement we run before every store takeover, and you can book it standalone. We spend three to five working days on your store, produce the scored rubric across every installed app, run the DevTools and Lighthouse measurements on a real throttled mobile profile, identify the kill and optimise lists with revenue impact modelled, and deliver the staging and rollback protocol written for your specific theme. You get a report, a recorded walkthrough, and a spreadsheet you can hand to your next developer. Price is flat, timeline is fixed, and the deliverable exists whether or not you hire us for the implementation that follows.

Most of our audit clients have already spent more than our fee on apps they are about to uninstall. That is the unpleasant arithmetic of Shopify app bloat in 2026, and the reason the audit exists at all. Book it, run it yourself, or ignore it. Just stop shipping a twenty four app theme into a 2026 Core Web Vitals regime that is going to eat you alive at Black Friday.