Leftover Shopify App Code Is Slowing Your Store: How to Find and Remove It Safely

Devi runs Saltgrove, a $1.8M home-fragrance brand on Shopify. Her mobile speed score had drifted from the mid-60s down to 31 over about eight months, and she couldn’t point to a single thing that broke. No redesign. No big new app. Just a slow, quiet slide.

So she did what most merchants do. She blamed her theme, paid a developer to “optimize images,” and watched the score tick up four points and settle right back down.

The actual culprit was sitting in her theme files: snippets, script tags, and asset references from eleven apps she’d installed over three years and uninstalled along the way. The apps were gone from her admin. Their code was still loading on every page, every visit, for thousands of shoppers who would never benefit from a single line of it.

A merchant we got on a teardown call with put it about as plainly as it gets: “I stopped installing every app that promised to increase conversions. At one point my store had 14 apps running simultaneously.” That’s the part people miss. The damage isn’t only the apps you’re running now. It’s the ghosts of the ones you fired.

Why uninstalling never actually clears the code

Here’s the thing nobody tells you when you click “Delete” in the app store.

When a Shopify app installs, it often writes code directly into your theme: a snippet here, a <script> tag in theme.liquid, a chunk of Liquid in your product or cart template, maybe a CSS file dumped into your assets. That injected code is yours now, technically. It lives in your theme, not in the app.

Uninstalling the app stops your subscription and removes it from the admin. It does not reach back into your theme and tidy up. Most apps never built that cleanup step, and the ones that did only clean up if you uninstall the “right” way, from the theme they were installed on, before you’ve since duplicated or switched themes.

So the snippet stays. The script tag stays. And every time a shopper loads a page, their browser dutifully fetches a JavaScript file from a service that no longer does anything, waits for it, and renders a little slower because of it. Multiply that by eleven dead apps and you’ve got a theme carrying a backpack full of bricks.

The app is gone. The tax it left behind is not.

The symptoms that point at ghosts

Dead app code rarely announces itself. It shows up as a pattern, and once you’ve seen the pattern you can’t unsee it.

The clearest tell is a speed score that declined gradually over months instead of dropping the day you launched something. Gradual decline is the signature of accumulation. Each app you tried and abandoned added a little weight, and the curve bent down so slowly that no single week looked alarming.

The next tell lives in your browser. Open your store, right-click, choose Inspect, and watch the Network tab as the page loads. You’ll often see requests going out to domains for tools you swear you removed, a review widget you ditched last spring, an upsell app you trialed for a week, a currency converter from two themes ago. Those requests are your ghosts waving back.

You might also notice console errors referencing apps that no longer exist, or a flash of a broken element (an empty review-stars box, a phantom “free gift” banner) that appears for half a second before the page settles. That flicker is leftover Liquid trying to render against an app that isn’t there to feed it data.

None of these will show up in your Shopify admin. The admin thinks the app is gone, because as far as billing is concerned, it is. So you go looking in the one place the evidence isn’t.

Finding the dead code without guessing

You don’t want to go hunting blind, deleting lines and praying. There’s a calmer way to do this.

Start with a coverage pass. Chrome’s DevTools has a Coverage tab that shows you how much of each loaded JavaScript and CSS file actually gets used on a page. App leftovers tend to light up as files that load but go almost entirely unused, which is a strong hint you’re looking at something your store no longer needs.

Then go into the theme code editor (Online Store, Themes, Edit code) and use the search box. Search your theme for the names of apps you remember removing. Search for telltale prefixes, since a lot of apps wrap their injected code in comments like <!-- BEGIN app-name --> and <!-- END app-name -->, which makes the whole block easy to spot. Check the usual hiding spots: theme.liquid, the cart template, your product templates, and the snippets and assets folders for files named after apps you’ve killed.

Keep a list as you go. Write down the file, the line range, and which dead app it belongs to. You’re building a removal plan, not removing anything yet. The discipline of cataloguing first is what separates a clean cleanup from a Saturday spent restoring a backup.

One honest caveat. Some injected code is shared or ambiguous, and not every orphaned-looking snippet is safe to yank. When you’re not sure who put a block there or what it touches, flag it and leave it for the duplicate-theme test below.

The safe way to rip it out

Now the rule that saves careers: never edit your live theme to do this.

Duplicate the theme first. In the admin, go to your themes, hit the three-dot menu on the live theme, and choose Duplicate. You now have a sandbox copy that real customers never see. Every change you’re about to make happens there.

Work through your catalogue one app at a time. Remove a block, save, and preview the duplicated theme. Click through the pages that block touched: if it was a review app, check product pages; if it was an upsell, walk the cart and checkout entry; if it was a currency tool, switch markets and watch. Test on mobile, because that’s where most of your traffic and most of your speed pain actually lives.

Removing one app’s code per pass matters more than it sounds. If you strip out six apps in one go and something breaks, you’ve got six suspects and no way to tell which line did it. One at a time, you always know exactly what changed. It’s slower. It’s also the difference between a controlled cleanup and a panic.

When the duplicate is clean, fast, and clicks through without errors, publish it. Keep the old theme as a backup for a couple of weeks before you delete it, just in case a problem surfaces on a page you forgot to test. And run your store speed report before and after, so you’ve got a real number to show for the work instead of a vibe.

When it’s the app developer’s job, not yours

You don’t always have to be the one with the scalpel.

If you remember which app left a particular mess, the developer often has an uninstall or cleanup routine they can run, or clear documentation on exactly what they inject and where. A quick support email (“I removed your app, what code do I need to pull from my theme, and where does it live?”) can hand you a precise list instead of an afternoon of detective work. Good app teams answer this fast, because they get asked it constantly.

This is also the moment to be a little ruthless about who you trust with theme access going forward. An app that injects deep, undocumented Liquid into your templates is an app that will be painful to remove later. That’s a real cost, and it belongs in your decision before you install, not after you’re trying to evict it.

App embeds changed the game, and not always for the better

Newer Shopify themes lean on app embed blocks, and they’re a genuine improvement for exactly this problem.

App embeds and app blocks let an app add functionality through the theme editor instead of hard-writing code into your Liquid files. The payoff is clean removal: toggle the embed off, and the app’s footprint goes with it, no manual surgery required. If you’re choosing between two apps and one uses theme app extensions while the other pastes raw script tags into theme.liquid, the embed-based one is the safer long-term bet by a wide margin. Shopify’s theme architecture docs spell out how these blocks are meant to work.

But, and this is the catch, embeds only protect you going forward. Every app you installed in the old-school way, especially on Shopify 1.0 themes or before app blocks were common, still left its code the hard way. The clean future doesn’t retroactively scrub your messy past. You still have to do the audit once.

A reinstall policy that keeps you lean

The cleanup is the easy part. Staying clean is the discipline.

The merchant from earlier had the right instinct: stop installing every app that whispers “more conversions.” Each one is a small bet that adds permanent weight whether or not it pays off, and the weight outlives the trial. Before you install anything, ask what it injects, whether it uses app embeds, and how you’d remove it. Trial apps on a duplicated theme, not your live one, so a week-long experiment never leaves a year-long scar.

And every quarter, walk your installed apps list and your network requests with fresh eyes. Anything you’re not actively using, or paying for and not using, comes out. Treat app debt like any other debt. Small, regular payments beat one terrifying balloon payment when your speed score finally falls off a cliff.

What we keep telling clients

Store speed gets treated like a dark art, something you fix by hiring a specialist to sprinkle magic on your images. Most of the time it’s nothing of the sort. It’s housekeeping.

The brands with fast stores usually aren’t running some exotic optimization stack. They’re just carrying less. They install deliberately, remove cleanly, and don’t let three years of abandoned experiments pile up in their theme files where every visitor pays the bill.

There’s something a little uncomfortable in that, because it means the slowness was self-inflicted and the fix doesn’t require a hero. It requires an afternoon, a duplicated theme, and the patience to remove one thing at a time. Not glamorous. Just effective.

Devi spent a Saturday on it. She catalogued eleven dead apps, pulled their code on a duplicate theme one pass at a time, leaned on two of the original developers for their removal notes, and published the clean version on Sunday night. Her mobile score went from 31 back into the high 50s on the same theme, same products, same traffic. She didn’t add anything. She just stopped carrying what she’d already thrown away.

Questions we get every week

Will removing app code break my store? It can, but only if you edit your live theme directly, which is exactly why you duplicate it first and test the copy. Remove one app’s code per pass, click through the pages it touched, publish only once the duplicate is clean, and the risk stays low and fully reversible.

How do I know which code belongs to which app? Search your theme for the app’s name and for comment markers like “BEGIN” and “END” wrapped around injected blocks, since many apps tag their code that way. Watching the Network tab while a page loads also reveals requests going to services you’ve removed. When a block is ambiguous, leave it and test removal on the duplicate theme before committing.

Does uninstalling an app from the admin remove its code automatically? Usually not. Uninstalling ends your subscription and removes the app from your admin. But the code the app wrote into your theme typically stays behind, quietly loading on every page. Newer apps that use theme app embeds are the exception, since toggling those off removes their footprint cleanly.

How often should I audit for leftover code? A quick quarterly pass is plenty for most stores, walking your installed apps and your network requests and cutting anything you’re not actively using. If you trial a lot of apps, do it monthly. The point is to keep app debt small and regular instead of letting it balloon until your speed score forces the issue.

If your speed score has been sliding and you suspect dead app code is the cause, talk to Monkey Man and we’ll audit the theme with you.