Ghost Scripts: What They Are, How to Find Them, and How to Remove Them Without Breaking Your Store

I wasn't looking for ghost scripts the first time I found them. I was trying to figure out why a store with good traffic and good products converted so poorly on mobile. The homepage felt sluggish. The Add to Cart button appeared before it was actually clickable. Checkout was inconsistent in ways I couldn't explain from the analytics.

So I opened Chrome DevTools, switched to a throttled 4G connection, and reloaded the homepage.

Instead of a clean loading sequence, I saw dozens of JavaScript requests firing before the page became interactive. Some belonged to apps the merchant was actively using. Others referenced domains that weren't in their Shopify Apps list. The apps were gone. The code wasn't.

That was the moment I stopped thinking about apps and started thinking about architecture.

Deleting an app from Shopify removes the tenant. It doesn't demolish the building. The JavaScript the app injected into your theme stays there, loading on every page, competing for the browser's main thread, making network requests to servers that may no longer exist. Most founders have no idea this is happening. It doesn't show up as an error. It doesn't trigger an alert. It just quietly makes the store slower and harder to buy from, every single day.

This post is the definitive resource on ghost scripts in the Shopify CRO context. What they are, how they got there, the three distinct categories most people confuse, how to find them with Chrome DevTools, what they cost you in LCP and revenue, and how to remove them without breaking your live store.

What Ghost Scripts Actually Are (The Definition Google Is Missing)

If you search "ghost scripts shopify" today, Google's AI Overview conflates three completely different things: Ghost Apps (custom private apps), the legacy Shopify Scripts feature that shut down June 30, 2026, and Ghost CMS integrations with Shopify. None of those are what we're talking about.

In the Conversion Engineering context, a ghost script is JavaScript that continues loading on your Shopify store after the app that installed it has been deleted.

Here's the mechanism. When you install a Shopify app, depending on how it's built, it may do any combination of the following: inject Liquid code directly into your theme files, create snippets inside the theme, add script tags to your theme.liquid, register App Embeds inside the Theme Editor, store configuration inside metafields, install Theme App Extensions, create tracking pixels, or ask developers to paste installation code manually.

When you click Uninstall in your Shopify dashboard, Shopify removes the application itself. It doesn't necessarily remove everything the application ever wrote into your store. Some modern Theme App Extensions clean up after themselves better than older installation methods. But many stores have years of legacy customizations layered on top of one another, and those remnants continue loading long after the app disappears.

The browser doesn't know any of this. It doesn't care whether JavaScript serves a business purpose. If it's referenced in the page, the browser downloads it, parses it, compiles it, and often executes it anyway. Every unnecessary request competes with the resources that actually matter: hero images, product content, payment buttons, and customer interactions.

That's why I don't describe ghost scripts as a performance problem. I describe them as a revenue problem.

The Three Categories of Dead Code (Most People Only Know One)

Most discussions about ghost scripts stop at one idea: delete the leftover JavaScript from uninstalled apps. That's only one piece of it. After auditing dozens of Shopify stores, I separate dead code into three distinct categories. Each behaves differently. Each requires a different removal strategy.

Category 1: Ghost Scripts

These are the most straightforward. An app is deleted. Its JavaScript still loads. Usually because a script tag remains in theme.liquid, the theme still references it through a Liquid render call, or an old installation wasn't fully reversed. Ghost scripts are visible in the Network panel and relatively simple to remove once identified. They're what most people picture when they hear the term.

Category 2: Zombie Embeds

These are the ones I see most frequently in 2026, and they're harder to catch. Modern Shopify stores rely heavily on Theme App Extensions, App Embeds, and custom app blocks injected into the storefront. Sometimes the merchant disables the feature. Sometimes the app subscription expires. Sometimes the app changes its functionality entirely. But the storefront still loads initialization code for those embeds. Nothing visible appears. The browser still downloads and executes JavaScript. The feature is effectively dead. The code isn't. That's why I call them zombie embeds. They're neither active nor removed. They're just consuming resources.

Category 3: Orphaned Snippets

These cause the most confusion, even among experienced Shopify developers. Imagine a developer manually installs an app five years ago. The installation adds Liquid snippets, includes, helper files, and section references to the theme. Later, someone uninstalls the app. The snippets remain. Months later, another developer redesigns the theme. The references become buried inside inherited code. Eventually nobody remembers why they exist. They aren't obviously broken. They're simply forgotten. Because Liquid renders them quietly, orphaned snippets often escape routine performance reviews entirely.

The category that causes the most cumulative damage isn't actually deleted app scripts. It's marketing and analytics accumulations. Every agency that touches a store installs something. Meta Pixel, TikTok, Pinterest, Hotjar, Clarity, LinkedIn Insight, GA4, heatmaps, session replay, affiliate platforms, A/B testing tools, email capture. Very few agencies remove anything when they leave. After several years, the storefront becomes a museum of previous marketing strategies. Individually, each integration seems harmless. Collectively, they create significant JavaScript execution costs before the page becomes interactive. This is the exact gap between what your Apps dashboard shows and what your browser is actually loading, and it's rarely the apps you're paying for that cause the damage.

Why do experienced developers miss this? Most search for errors. Ghost code rarely throws errors. It loads successfully. It executes successfully. It simply shouldn't exist anymore. The store technically works. The checkout technically works. The browser technically finishes loading. Everything passes functional testing. Only when you inspect the network waterfall, script execution timeline, and main thread activity do you realize how much unnecessary work the browser performs before the customer can actually use the page.

The CPG Brand That Had 847KB of Dead Code

The clearest example I can give you started with a founder who was convinced they had a marketing problem.

They were spending around $60,000 per month on Meta and Google Ads, generating plenty of qualified traffic, but their conversion rate had plateaued at 1.0%. The conversation started exactly the way most audits do: "Do we need better ads? Should we redesign the homepage? Would SEO help?"

Those are reasonable questions if you assume the store is healthy.

I didn't.

The first thing we did wasn't open GA4 or Shopify Analytics. We opened Chrome DevTools.

I always start the same way: open DevTools, go to the Network tab, disable cache, throttle to Fast 4G, hard reload the homepage. I'm not looking for a Lighthouse score. I'm watching the waterfall.

A healthy Shopify store has a predictable loading sequence. The HTML arrives, critical CSS loads, the hero image starts rendering, Shopify's core assets initialize, and the page becomes interactive relatively quickly. This waterfall looked nothing like that.

Instead of seeing the browser prioritize rendering the storefront, we saw dozens of third-party requests competing for bandwidth before the customer could meaningfully interact with the page. Marketing pixels. Review widgets. Upsell scripts. Live chat. Loyalty software. Subscription tools. Heatmaps. Tracking libraries. Many of them weren't even used anymore. Some were making requests to endpoints that no longer existed. Others returned JavaScript that still downloaded successfully despite the associated Shopify app having been removed years earlier.

The browser wasn't asking whether those scripts were useful. It was simply executing everything it had been instructed to load.

Then we opened the theme files. Inside theme.liquid we immediately found multiple script references pointing to apps that weren't installed. In the Snippets folder, several Liquid snippets still referenced review platforms, abandoned upsell tools, marketing widgets, and old analytics integrations. The Apps dashboard looked clean. The codebase wasn't.

The biggest surprise wasn't the number of scripts. It was the total weight. When we finished cataloguing everything, we calculated roughly 847KB of unnecessary JavaScript loading on virtually every page of the store. Nearly a megabyte of code contributing nothing to the customer experience.

On a high-end desktop with fast WiFi, it might feel like a minor inconvenience. On a mid-range Android over 4G, it becomes a completely different experience. Every additional script increases parsing, compilation, and execution time before the browser can respond to user interactions. The Add to Cart button appeared on screen but the browser was still processing a queue of dead JavaScript before it would respond to a tap.

When we showed the founder their Apps page, they counted fewer than ten active apps. Then we showed them the network waterfall. Then the script inventory. Their first response was: "Wait, we deleted that app two years ago." Then another one. And another.

The realization wasn't that the store had unnecessary code. It was that they'd been paying $60,000 every month to send qualified traffic into a storefront carrying years of technical debt they didn't even know existed.

Ghost scripts rarely fail dramatically. They create tiny delays that accumulate. The homepage takes another half-second to become interactive. The Add to Cart button appears but doesn't respond immediately. The browser spends extra time executing JavaScript before processing user input. Customers don't think "this website has too many legacy scripts." They think "this site feels slow." Or worse: "this button isn't working."

We didn't redesign the homepage. We didn't rewrite product descriptions. We didn't launch new campaigns. We removed ghost scripts, cleaned unused Liquid references, reorganized script execution, eliminated unnecessary third-party requests, refactored sections of the theme architecture, resolved checkout layout shifts, and fixed iOS Safari interaction issues. We removed friction instead of adding features.

Mobile LCP fell from 5.4 seconds to 1.4 seconds. Akamai's research established that a 100-millisecond delay in load time reduces conversion rates by 7%. Going from 5.4 seconds to 1.4 seconds isn't a minor improvement. It's the difference between a store that converts and one that doesn't. Conversion rate moved from 1.0% to 10.0%. Monthly revenue went from $30,000 to $100,000 on the same advertising budget. No new traffic. No new media buyer. No SEO campaign. The customers had been there all along. The store was simply getting in their way.

The full breakdown is in the CPG brand case study.

What Ghost Scripts Actually Cost: LCP, Revenue, and the Mobile Gap

The impact isn't abstract. It shows up in three specific numbers you can measure right now.

LCP (Largest Contentful Paint): Ghost scripts load before the browser can render your hero image or main product content. Every dead script in the critical path delays LCP. If your mobile LCP is above 2.5 seconds, ghost scripts are almost certainly a contributing factor. Above 4 seconds means meaningful chunks of your paid traffic are bouncing before the page finishes loading. LCP is also one of the three Core Web Vitals Google uses as a ranking signal, so ghost script bloat damages organic search visibility at the same time it suppresses paid traffic conversion.

The mobile CVR gap: Mobile CPUs are significantly weaker than desktop processors. Dead JavaScript that costs 50 milliseconds on a MacBook costs 400 milliseconds on a mid-range Android. When your store has 847KB of ghost scripts, desktop visitors brute-force through them fast enough that the experience feels acceptable. Mobile visitors choke. That's why almost every store we audit shows desktop CVR around 2.5% to 3% and mobile CVR stuck at 1% or lower. The gap isn't behavioral. It's technical. The full explanation is in the post on why your mobile CVR is half your desktop CVR.

Revenue cost: Calculate it directly. Take your monthly sessions, multiply by your current CVR and average order value to get your current monthly revenue. Now multiply those same sessions by your category benchmark CVR. The difference is your monthly revenue leak. That's what the dead code is costing you every single month, not a one-time cost, a recurring loss until the scripts are removed. Your category benchmark and the revenue gap formula are in the Shopify conversion rate benchmarks by niche.

The CRO industry doesn't talk about execution order enough. Most conversations focus on persuasion: headlines, trust badges, reviews, scarcity. Very few ask when JavaScript executes. A small script loaded at the wrong moment can delay interaction more than a larger script deferred until after the page becomes usable. That's why audits don't just inventory scripts. They analyze when they execute, what they block, and whether they deserve to be in the critical rendering path at all. That same execution order is also why Shopify LCP is often a JavaScript problem rather than an image problem.

Before/After: Three Stores, Three Ghost Script Patterns

Ghost script removal is rarely the only fix. Conversion rate is the result of dozens of interacting factors. What I've consistently observed is that ghost scripts remove a major source of technical friction, and once that friction disappears, every other optimization has a chance to perform properly. Here's what the before/after looks like across different types of stores.

The Apparel Brand: Years of Accumulated Technical Debt

847KB of unnecessary JavaScript loading on virtually every page. Much of it came from apps deleted months or even years earlier, alongside legacy tracking libraries and abandoned marketing integrations. Each one seemed insignificant. Together they prevented the browser from prioritizing the storefront. LCP: 5.4 seconds to 1.4 seconds. CVR: 1.0% to 10.0%. Monthly revenue: $30,000 to $100,000. Nothing changed on the marketing side. The same campaigns, the same products, the same ad spend. The difference was that customers could finally interact with the store without fighting the browser.

The CPG Brand: Marketing Accumulation, Not Deleted Apps

This one is more common than most founders realize. The majority of unnecessary JavaScript wasn't coming from deleted apps. It came from marketing technologies that were technically still installed but no longer used: old personalization engines, inactive review widgets, duplicate analytics implementations, legacy campaign tracking. Dozens of small libraries competing for execution time rather than one large library. The Add to Cart button was visually appearing before it became responsive. Mobile conversion was significantly below desktop. The founder believed this was normal because the page "looked loaded." From the customer's perspective, it wasn't. After removing obsolete scripts and deferring non-critical marketing technologies, interactivity improved immediately and the mobile CVR gap narrowed substantially.

The High-Growth DTC Store: Execution Order, Not Weight

This is the pattern most guides miss. The store wasn't particularly slow according to Lighthouse. On paper it looked acceptable. Customers still complained the site felt sluggish. Performance metrics measure speed. Customers experience responsiveness. The problem wasn't download size. It was execution order. Several third-party scripts executed before the browser became interactive. The page looked finished. The browser wasn't ready. Customers tapped Add to Cart and nothing happened immediately. Some abandoned altogether. By moving non-essential JavaScript out of the critical rendering path and removing obsolete integrations, the storefront became responsive almost immediately after rendering. The improvement didn't come from making the page prettier. It came from making it usable.

The pattern across every audit is consistent. The most damaging ghost script is rarely one catastrophic file. It's accumulation. Every app seems harmless when installed. Over three or four years, a store might add review apps, loyalty programs, shipping protection, heatmaps, chat widgets, affiliate platforms, A/B testing tools, personalization software, and abandoned pixels. Individually they cost milliseconds. Collectively they cost revenue.

How to Find Ghost Scripts: The 10-Step Chrome DevTools Walkthrough

Most guides about ghost scripts end with one sentence: "Remove unused JavaScript." That sounds simple. It isn't. Removing the wrong script can break your navigation, checkout, analytics, or payment integrations. This process isn't just about finding ghost scripts. It's about proving they're unnecessary before removing them.

Step 1: Establish Your Baseline Before Touching Anything

Before you touch anything, record three numbers. Mobile LCP from PageSpeed Insights. Mobile vs Desktop CVR from GA4 (Reports, Acquisition, Traffic Acquisition, Device Category). Checkout completion rate from Shopify Analytics (Analytics, Conversion Funnel). These three metrics tell you whether script removal actually improves the business after deployment. Never optimize without a baseline. The full five-metric diagnostic sequence is in the guide on how to measure Shopify conversion rate.

Step 2: Open Chrome DevTools the Right Way

Open your storefront in Chrome. Right-click anywhere and select Inspect. Select the Network tab. Then: enable Disable Cache (checkbox in the Network tab), find the throttling dropdown and set it to Fast 4G, and perform a Hard Reload (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac). Now you're watching the store exactly as a first-time mobile visitor would. Ignore the Lighthouse score. Watch the waterfall.

Step 3: Look for Third-Party Requests

Filter the Network panel by JS using the filter bar at the top. Now ask: which scripts come from Shopify's own CDN (cdn.shopify.com)? Which come from third parties? Which belong to apps you still use? Which belong to domains nobody recognizes? This is where the investigation starts. Many founders immediately spot domains from tools they haven't thought about in years.

Step 4: Count Your JavaScript Weight

Look at the Size column in the Network panel. You're not searching for one enormous file. You're looking for accumulation. Five unnecessary scripts at 80KB each are usually worse than one optimized 400KB library because each introduces additional requests, parsing, compilation, and execution. If your total JavaScript weight is above 500KB on the homepage, you have a problem worth investigating. If it's above 847KB, you have the pattern we described in the CPG case study.

Step 5: Count Your Total Network Requests

Look at the request count at the bottom of the Network panel. A clean Shopify store should have between 30 and 60 total network requests on the homepage. Above 100 requests indicates serious script bloat. Look specifically for any requests shown in red. Those are 404 errors, scripts calling servers that no longer exist. Every red row is a confirmed ghost script. It has nothing left to do and it's still taking up execution time.

Step 6: Open the Sources Panel

The Network tab tells you what loaded. The Sources tab tells you where it came from. Switch to the Sources tab (next to Network in DevTools). Look through the domain folders in the left panel. You'll see a folder for each external domain that delivered a script to your page. Look for app names, marketing platforms, abandoned vendors, and duplicate libraries. Then compare what you see against the apps installed in your Shopify admin. If a domain appears in Sources but the app isn't in your installed list, you've likely found a ghost script.

Step 7: Search Your Theme Files

In your Shopify admin, go to Online Store, then Themes, then Edit Code. Open theme.liquid first and use Ctrl+F to search for the app names and vendor domains you found in Steps 3 and 6. Then open the Snippets folder and look through each file. Search for the terms "script", "render", "include", and any specific app names. You're looking for leftover snippets, obsolete Liquid references, and manually inserted script tags from old installation instructions. This is where you find the code that keeps running even after the app is gone.

Step 8: Check Theme App Embeds

Many merchants skip this step. Go to your Shopify admin, then Customize Theme (the blue button), then App Embeds (usually in the left sidebar). Look for disabled apps, unused integrations, experimental tools, and legacy marketing widgets. Sometimes the app is gone from the Apps dashboard but the embed is still toggled on in the theme editor. The embed still loads initialization code even when it has nothing to connect to.

Step 9: Verify Business Value Before Removing Anything

Before deleting any code, ask one question: what business function does this code still perform? If nobody can answer, investigate further. Don't remove code simply because it looks unfamiliar. Many integrations have non-obvious dependencies. A script that looks like an abandoned chat widget might be providing cross-domain session tracking that your attribution depends on. Verify before you remove.

Step 10: Test on a Duplicate Theme

This is the single rule that prevents expensive mistakes. Never edit your live theme. Duplicate it first. In Shopify admin, go to Online Store, Themes, and click the three-dot menu next to your current theme, then Duplicate. Remove one script category from the duplicate. Then test everything: homepage, collection pages, product pages, search, cart, checkout, analytics, pixels, on both mobile Safari and Android Chrome. Only after confirming nothing breaks should changes be published to the live store.

How to Remove Ghost Scripts Safely

Finding ghost scripts and safely removing them are two different problems. Here's the workflow that prevents breaking things. Ghost script removal fits inside a larger diagnostic sequence: the full Shopify CRO audit process covers where ghost script identification sits relative to LCP measurement, checkout CLS diagnosis, and revenue quantification, so you know which fix to prioritize first.

The duplicate-first rule: Every removal happens on a duplicate theme. Not the live store. The staging copy. Always.

Work one category at a time: Remove all the clearly dead script tags from theme.liquid first. Test. Then move to Snippets and remove orphaned files. Test. Then check App Embeds. Test. Never batch multiple categories into one change because you won't know which removal caused a problem if something breaks.

The cross-reference method: Build a simple spreadsheet. Column A lists every external domain found in your Network waterfall. Column B lists every app in your installed Shopify apps list with its associated domain. Any domain in Column A that doesn't have a match in Column B is a candidate for removal. Any domain with a match stays.

The test sequence: After removing any script, test in this exact order. Homepage on Chrome desktop. Homepage on Chrome mobile emulation. Full purchase flow on a real iPhone in Safari. Cart open and close five times. Checkout through to the payment step. Analytics in GA4 verifying events still fire. Only after all six pass should you move to the next removal.

Measure after deployment: After publishing to the live store, wait 48 hours and pull these numbers again: mobile LCP from PageSpeed Insights, total network requests on the homepage, mobile vs desktop CVR from GA4. If LCP improved and requests dropped, you've confirmed the ghost scripts were creating measurable friction. The full 27-check diagnostic that this fits into is in the Shopify CRO checklist, specifically Items 9 through 15 in the Scripts layer.

The one principle I won't break: never remove code just because you don't recognize it. Remove code only after you've proved it's unnecessary. Ghost scripts are easy to identify. Safe removal is what requires experience.

Ghost script cleanup is an engineering exercise, not housekeeping. The goal isn't to have fewer files in the theme. The goal is to ensure every line of code that reaches a customer's browser earns its place by contributing to the buying experience. If it doesn't create value, it's creating friction. That's the core principle behind Shopify Speed Optimization at the architecture level, and it's the exact workflow we walk through step by step in the complete Shopify speed optimization engineering guide. If you're comparing vendors before committing to anyone for this kind of work, we ranked six real agencies by documented LCP results instead of PageSpeed scores.

Why Running A/B Tests Before Removing Ghost Scripts Is a Waste of Money

Imagine running an A/B test while your homepage takes 5 seconds to load. Version A wins by 3%. Version B loses. Did Version A actually have better messaging? Or did it simply perform slightly less badly despite the technical bottleneck? You can't know. The data looks conclusive. It means nothing.

We took over from a brand that had been paying a traditional CRO agency for 6 months. That entire time, the agency ran A/B tests on button colors and headline variations while LCP sat at 5.1 seconds from Liquid template bloat and ghost script accumulation. They were testing two versions of a broken experience. Whichever variant "won" did so despite the technical problems, not because of the copy change. When we stopped the tests, removed the dead code, and dropped LCP to 1.4 seconds, more revenue came in during the first month than from 6 months of creative testing combined.

Fix the technical foundation first. Then test. That's the only sequence that produces data you can trust. If the ghost scripts are connected to a deeper Liquid architecture problem, the relationship between dead code and server response time is covered in the post on what Liquid bloat does to your LCP. If you're also deciding whether to invest in fixing your store vs scaling SEO, the revenue math is in Shopify CRO vs SEO.

The June 2026 Shopify Scripts Deprecation: A Note on Terminology

Shopify Scripts (the legacy Plus feature for creating discount logic and shipping rules) shut down permanently on June 30, 2026. If you search "ghost scripts shopify" right now, a lot of the SERP is about that deprecation because thousands of Plus stores just ran migration audits.

Those two things are not the same.

Legacy Shopify Scripts were a development tool for Plus merchants. Ghost scripts in the CRO context are dead JavaScript from deleted apps loading in your storefront. The migration audits that happened for the Shopify Scripts deprecation did, however, surface a lot of the second type: developers found years of dead code in theme files while they were in there cleaning up the legacy Script editor logic.

If your team ran a Scripts migration audit recently, it's worth going one layer deeper and checking whether the review also covered the ghost script categories described above. The migration fixes the official Shopify Scripts. It doesn't automatically clean up the JavaScript graveyard left by three years of app installs and uninstalls.

Frequently Asked Questions: Ghost Scripts on Shopify

What are ghost scripts on a Shopify store?

Ghost scripts are JavaScript files that continue loading on your Shopify store after the app that installed them has been deleted. When you uninstall an app from the Shopify dashboard, the app is removed but the code it injected into your theme files stays. That code loads on every page view, competes for the browser's main thread, and makes network requests to servers that may no longer exist. On stores with two or more years of app history, this dead code can accumulate to hundreds of kilobytes loading silently on every session.

How do I find ghost scripts on my Shopify store?

Open Chrome DevTools (press F12), click the Network tab, set throttling to Fast 4G, and reload your homepage. Filter the Network panel by JS and look for any requests shown in red. Those are 404 errors: scripts calling servers that no longer exist. Those are confirmed ghost scripts. Also look at the total number of JavaScript files loading before your hero image appears. More than 5 or 6 scripts before your main content means you almost certainly have dead code. Then open your theme files in the Shopify code editor and search for script tags referencing domains that don't match your currently installed apps.

What is the difference between ghost scripts, zombie embeds, and orphaned snippets?

Ghost scripts are JavaScript files from deleted apps that still load via script tags in your theme. Zombie embeds are Theme App Extensions or App Embeds that remain enabled or continue loading initialization code despite the app being gone or inactive. Orphaned snippets are Liquid files and template references that survive inside the theme long after the software they supported has disappeared. All three are categories of dead code, but each one lives in a different part of your theme and requires a different discovery and removal process.

Do ghost scripts affect LCP?

Yes, directly. Ghost scripts load in the critical rendering path before the browser can build and display your page content. Every dead script adds to the queue of work the browser must complete before your hero image or product content becomes visible. If your mobile LCP is above 2.5 seconds, ghost scripts are a likely contributor. The CPG store referenced in this post had an LCP of 5.4 seconds from 847KB of dead JavaScript. After removal, LCP dropped to 1.4 seconds with no other changes to the page content or images.

Can ghost scripts cause a low conversion rate?

Yes. Ghost scripts delay page interactivity, which means the Add to Cart button appears on screen before it's actually ready to respond to taps. Mobile users tap the button, nothing happens, and they assume the store is broken. Ghost scripts also push mobile LCP higher, which increases bounce rates on paid traffic before the customer even sees the product. The specific revenue cost depends on your traffic volume and ad spend. A store spending $60,000 a month on ads with a 1% CVR caused by ghost script bloat is losing the difference between 1% and its category benchmark of 3% to 5% every single month.

How do I safely remove ghost scripts from Shopify?

The single most important rule: never edit your live theme. Duplicate it first. Then work one category at a time: remove script tags from theme.liquid, test everything, then move to orphaned Liquid snippets in the Snippets folder, test again, then check App Embeds in the theme editor. After each removal, test the full purchase flow on a real iPhone in Safari and a real Android in Chrome, verify that analytics events still fire in GA4, and confirm your checkout works end to end. Only after all tests pass should you publish changes to the live store.

How many JavaScript requests should a Shopify homepage have?

A clean Shopify store should have between 30 and 60 total network requests on the homepage, with no more than 5 or 6 JavaScript files loading before the hero image appears. Above 100 total requests indicates serious script bloat. If you're seeing more than 10 JavaScript files load before your main content appears, you almost certainly have ghost scripts from deleted apps and should run a full script inventory before making any other changes.

Are ghost scripts the same as the Shopify Scripts that were deprecated in 2026?

No. The Shopify Scripts that were deprecated June 30, 2026 were a specific Plus-only development tool for creating discount and shipping logic. Ghost scripts in the CRO context are dead JavaScript from deleted third-party apps that remain in your theme files. They're two completely different things. However, if your team ran a Shopify Scripts migration audit recently, it's worth checking whether that review also covered dead JavaScript from old app installs, since migration audits often surface both issues at the same time.

Article by

Muhammad Usama

Founder & Head Conversion Engineer

Founder & Head Conversion Engineer with 8+ years of technical engineering experience. I bridge the gap between full-stack development and e-commerce growth, specializing in tearing down Shopify architectures, eliminating code-level friction, and building high-performance infrastructure for 7- and 8-figure brands.