Uninstalled Shopify Apps Still Slowing Your Theme? Fix It
You uninstalled the reviews app, the popup app and the old chat widget months ago, yet PageSpeed still lists their scripts and your theme still feels heavy. That is not your imagination. Removing an app from the Shopify admin does not always remove the code it added to your theme. This guide shows where that leftover code hides, how to find it in an hour, and how to remove it without breaking a live store.
Every platform detail below comes from Shopify's developer documentation, checked on 5 November 2026. Code samples use placeholder app names, so search your own theme for the real ones.
Why does an uninstalled app keep slowing your store?
Because the uninstall button removes the app, not every change the app made. Shopify says this plainly in its guide to migrating to theme app extensions: "Uninstalling apps often leaves the code edits, or ghost code, behind in the theme, which can cause quality and performance issues and takes merchants off their theme upgrade paths."
How much is left behind depends on how the app connected to your theme in the first place. There are three ways, and they behave very differently on uninstall.
- Script tags. The older method, where the app tells Shopify to load a JavaScript file on your storefront. Shopify's ScriptTag documentation says that when an app is uninstalled, "all of the script tags that it created are automatically removed along with it." These usually clean themselves up.
-
Direct theme edits. The app, or the developer who installed it, writes files into your theme: a snippet in the
snippetsfolder, a{% render %}line in a section, a<script>tag intheme.liquid. These are ordinary theme code. Shopify has no record that they belong to an app, so nothing removes them. - Theme app extensions. The current method, using app blocks and app embed blocks that you switch on in the theme editor. Shopify's docs say these "don't edit theme code", which is exactly why they are the clean option.
The problem is almost always the middle one. Any app installed on an older theme, any app whose setup guide said "paste this into theme.liquid", and any integration a freelancer wired in by hand will leave code behind unless someone removes it deliberately.

What does leftover app code actually look like?
It is rarely dramatic. Usually it is a handful of lines spread across several files. These are the places we check first.
-
Snippet files with the app's name. Files such as
snippets/reviewapp-widget.liquidorsnippets/popup-loader.liquid. Shopify's own audit guide notes that app-generated snippets often carry the app name in the filename. -
Render and include tags. A line like
{% render 'reviewapp-widget' %}inside a product section, the cart drawer or the footer. If the snippet file was deleted but this line was not, the storefront shows a visible Liquid error where the widget used to be. -
Script and stylesheet tags in theme.liquid. External files loaded in the
<head>on every single page, often withoutdefer, so they block rendering as well as wasting bandwidth. -
Inline configuration blocks. Small
<script>blocks that set a global variable for the app. Harmless on their own, but they tell you a loader was there too. - Tracking pixels pasted by hand. Old ad platform or heatmap tags added straight into the theme before the store moved to Shopify's Customer events.
- Template JSON references. In Online Store 2.0 themes, a section or block that pointed to a removed app can stay listed in a template's JSON file.
Here is the typical shape of it inside layout/theme.liquid:
<!-- Left by an uninstalled app -->
<script>window.reviewAppConfig = { shop: "yourstore.myshopify.com" };</script>
<script src="https://cdn.reviewapp.example/loader.js"></script>
<link rel="stylesheet" href="https://cdn.reviewapp.example/widget.css">
Three lines, but the loader script runs on every page for every visitor, for an app you no longer pay for.
How do you find leftover app code in your theme?
Work from the outside in: first see what the live store actually loads, then trace each unknown file back to the theme. This follows the steps in Shopify's guide to auditing and removing third-party scripts, which calls script removal "the highest-impact optimization for improving responsiveness and overall performance."
- List every domain your store loads from. Open your home page in Chrome, open DevTools, go to the Console and run the line below. It prints each host that served a file to the page.
- Repeat on a product page and a collection page. Shopify's guide warns that a script that looks unused on the home page might be doing real work on a product page, so check the main templates before deciding anything.
- Mark every domain you cannot name. Shopify's own domains and your current apps are expected. Anything else needs an owner.
- Search the theme code. In the Shopify admin, go to Online Store, Themes, and choose Edit code on a duplicate of your live theme. Search for each unknown domain and for the names of apps you have removed.
-
Check the usual files.
layout/theme.liquid, thesnippetsfolder, product and cart sections, and the template JSON files. - Confirm the cost before removing. Chrome's Network request blocking lets you block a domain, reload the page and compare. Shopify's guide walks through this exact test.
[...new Set(performance.getEntriesByType('resource')
.map(r => new URL(r.name).hostname))].sort()
The Coverage tab in DevTools (More tools, then Coverage) is the other quick win. It shows how much of each downloaded script never ran on that page. A file with almost all of its code unused, from a vendor you no longer use, is the clearest removal candidate you will find.
How do you remove it without breaking the store?
The risk in this work is not the deletion. It is deleting something that turns out to be in use, or leaving a reference to a file you removed. A careful order avoids both.
- Duplicate the live theme and do all the work on the copy. Never edit the published theme directly for this.
-
Remove references before files. Delete the
{% render %}or{% include %}lines first, then the snippet file. The reverse order is how stores end up showing a Liquid error in place of a widget. -
Remove script and stylesheet tags from
theme.liquidand any section that loads them. - Preview every template. Home, collection, product (including alternate product templates), cart, search, blog, and the customer account pages. Add a product to the cart and open the cart drawer.
- Check that current apps still work. Two apps sometimes share a library. Make sure the reviews, wishlist or subscription apps you still pay for render correctly.
- Measure, then publish. Run PageSpeed Insights on the preview and the live theme so you have a before and after. Publish the copy and keep the old theme unpublished for a few weeks in case you need to compare.

Photo: Markus Spiske via Flickr, CC0 1.0
If your theme has been customised heavily, this connects to a bigger habit. Every manual change you strip out now is one fewer conflict when you next update the theme, which we covered in our guide to updating a customised Shopify theme safely.
Do script tags matter now that Shopify is retiring them?
Yes, for a different reason. Shopify's script tag deprecation page sets out the timeline. Theme app extensions replaced script tags in 2021. Apps cannot create or update a script tag after 1 October 2026, and script tags stop running on storefronts on 1 March 2027. On the Order status page they already stopped on 26 August 2026.
That matters here in two ways. First, an app you still use that relies on a script tag will stop working on 1 March 2027 unless its developer moves it to a theme app extension. Second, the deadline does nothing about code that was pasted into your theme. A <script src> line in theme.liquid is not a script tag in Shopify's sense, so it will keep loading after March 2027 until someone deletes it. We explained the deadline itself in our post on the Shopify script tags deprecation in 2027.

Which apps leave the most code behind?
Shopify's audit guide names the categories that most often add weight to every page. Older versions of these apps were also often installed by pasting code into the theme, so they are the first names to search for.
- Review and rating apps, which Shopify notes sometimes load scripts on every page even though reviews show only on product pages.
- Chat widgets, which Shopify says "often load hundreds of kilobytes of JavaScript on every page, even when the chat is rarely used."
- Email capture popups, often loaded everywhere even when set to appear on a few pages.
- A/B testing tools, whose anti-flicker snippets delay rendering. Shopify recommends removing them when no test is running.
- Social feeds and embeds, which bring their own frameworks and tracking.
- Marketing pixels pasted into the theme instead of being set up through Customer events or the platform's own Shopify app.
For an app you are keeping, the fix is often to load it only where it is needed rather than to remove it. Shopify's example limits a review widget to product pages:
{% if template.name == 'product' %}
<script src="https://reviews.example.com/widget.js" defer></script>
{% endif %}
How often should you check for leftover code?
Three moments are worth building into your routine.
- Straight after any uninstall. Before you close the tab, search the theme for the app's name. It takes five minutes while you still remember what the app did.
- Before a theme update or redesign. Leftover code is easier to remove than to carry into a new theme and debug later.
- Once a quarter, alongside your app bill. Review what you pay for and what your storefront loads in the same sitting. Our Shopify app stack audit post has the full checklist for the billing side.
Keep a simple log of which apps were installed, when and how they were removed. It turns the next clean-up from detective work into a ten-minute job.
Is leftover code ever a security problem as well?
It can be. Shopify's security guidance points out that script tags load code from a URL merchants cannot see or switch off in the theme editor, and if an attacker controls that URL, their code runs on every page that loads it. The same logic applies to any external script hardcoded into your theme. If the app's company shuts down and its domain lapses, someone else can register it, and your theme will keep loading whatever they serve. Removing scripts from vendors you no longer use is good housekeeping for speed and for safety.
Want a second pair of eyes? Write to us at hello@exactwhy.com with the subject "Leftover app code check" and your store URL. We will list every third-party domain your home, collection and product pages load, mark the ones that look orphaned, and tell you what is safe to remove, free. If you would rather we do the clean-up on a duplicate theme and hand it back tested, we quote that after the review, and ongoing speed and app monitoring is available on a monthly retainer. You can also reach us through our contact page.