Why Your Shopify App Permissions Are Loading Resources You Stopped Paying For Years Ago
The Apps Are Gone But the Damage Is Still Running
We do a lot of Shopify audits. One of the most consistent findings across stores in the $2M to $20M range is not slow images, not unoptimized fonts, not lazy loading failures. It is resource requests firing on every page load for apps that the merchant uninstalled six, twelve, sometimes eighteen months ago.
This is not a fringe problem. It is the default outcome when a Shopify store has been running for more than two years and has cycled through more than a handful of apps.
When you install most Shopify apps, they inject code into your theme files. Some do it cleanly through theme app extensions and Shopify's app blocks. Many do not. They write directly into your theme.liquid file, your product.liquid, your cart.liquid, or your checkout scripts. When you uninstall the app from your Shopify admin, Shopify removes the app's access and billing. It does not remove the code. That part is on you. Most merchants never know this is how it works.
What you are left with is a store making DNS lookups, stylesheet requests, and JavaScript calls to third party servers that no longer have a valid response waiting. Sometimes those servers return a 404. Sometimes they time out. Sometimes they return a redirect. Every single one of those outcomes costs your customers time, and it costs you conversions.
What This Actually Looks Like in a Store Audit
When we open a store's network waterfall in Chrome DevTools or run a trace in WebPageTest, zombie app resources show up as a cluster of requests with high latency and no payload. You will see requests going out to domains like cdn.appname.io or assets.appname.com or tracking.vendorname.co, and the response is either a 404, a 410, or a long timeout before the browser gives up.
On one apparel brand we audited earlier this year, doing around $6M in annual revenue, we found eleven separate third party domains being called on every product page load. Four of those domains belonged to apps that had been uninstalled. Two of the four domains had gone completely dark, meaning the DNS lookup itself was failing and the browser was sitting in a wait state before moving on. That wait state was adding between 400 and 900 milliseconds to the time before the page became interactive.
That brand had done everything visible correctly. Images were compressed. Fonts were self hosted. They had a well structured theme. But their Core Web Vitals scores were consistently in the orange, and their mobile conversion rate was running about 40% below their desktop rate. The zombie requests were a significant part of the reason why.
Why This Keeps Happening and Why It Is Hard to Catch
The mechanism is easy to understand once you know it, but it is invisible in normal Shopify operations. When you log into your admin and look at installed apps, you see a clean list of what is active. There is no view that shows you what code those apps left behind in your theme. There is no alert that fires when an uninstalled app's resources start failing.
Most merchants do not manually inspect their theme.liquid file. Most agency partners doing ongoing work inherit a theme and assume it was handed over clean. Most CRO teams are testing button colors while 600 milliseconds of dead weight loads on every product page.
The tools that surface this are not complicated, but you have to know to look. A network waterfall in Chrome DevTools, filtered by domain, will show you every external resource request and whether it resolved. GTmetrix and WebPageTest both produce request lists you can sort by domain and response code. You are looking for requests to domains that are not yours, not a current CDN, and not an actively installed app. Any request returning a 4xx or timing out is a candidate for removal.
Cross reference those domains against your Shopify billing history. If you are making requests to a domain that belongs to an app you no longer pay for, that code needs to come out.
How to Actually Fix It Without Breaking Your Theme
Before you touch anything, duplicate your theme. This is non negotiable. Work on the duplicate, push it to a test URL, verify nothing breaks, then publish.
Open your theme.liquid file and search for script tags and link tags that reference external domains. Look for anything that calls out to a third party URL. Copy those domain names into a separate document and check them against your current installed apps. Anything that does not match an active app is a removal candidate.
Do the same for any app specific sections or snippets in your theme code. Many apps create their own snippet files and call them from within product or cart templates. Search your template files for render tags and include tags that reference snippets with app brand names in them. If the app is gone, the snippet and every reference to it should go too.
Some apps also write into the Additional Scripts section of your Shopify checkout settings. Open Settings, then Checkout, and scroll down to that field. We have found dead app code in checkout additional scripts on over half the stores we audit. This is particularly damaging because it affects the highest intent moment in your entire funnel.
After you remove the code, run a fresh network trace and confirm the requests are gone. Check your cart and checkout pages specifically, not just your homepage. Run a quick smoke test on add to cart, the checkout flow, and any active subscription or upsell functionality to confirm nothing that was referencing that code broke.
The Ongoing Maintenance Problem Nobody Talks About
The real issue is that this accumulates over time and there is no built in Shopify mechanism to stop it. Every app you try and remove creates another opportunity for leftover code. The only solution is a periodic technical audit of your theme code, ideally every six months if you are actively testing and installing new apps.
We recommend building a simple log every time you install or remove an app. Note what the app wrote into your theme, where it wrote it, and confirm removal at uninstall time. It takes five minutes and it prevents this problem from building up again.
A slow store is not always a lazy loading problem or an image size problem. Sometimes it is four dead apps from 2022 still making network calls on every page.
If you want to know exactly what is slowing your store down and what it is costing you in lost revenue, our conversion audit covers technical performance alongside the funnel and copy work. It is one of the fastest ways to find money that is already leaving your store.