How to Speed Up Your Shopify Store Before a Sale (The Step Everyone Skips)

Sale week looks the same in most Shopify shops I’ve talked to. Discount codes loaded. Email campaign written and scheduled. Promo banner up on the homepage. Maybe a few new product photos. Everyone’s focused on getting people to the store.

There’s one step that rarely makes the list: checking whether the store itself is ready for the traffic.

I don’t mean the obvious things — image compression, theme choice, the Shopify speed score in your admin. Most merchants tick those off at some point. I mean the layer underneath, the one that builds up quietly over months and only shows itself when the traffic arrives.

The bit that accumulates without being noticed

Every Shopify app you install does more than appear in your dashboard. It injects something into your theme. A CSS file for its widget. A JavaScript snippet for tracking. A Liquid block that renders an element on a product page. Sometimes all three. When the app is working, you see the feature, and the code earns its keep.

Then you uninstall the app. The dashboard tile disappears. The billing stops. You move on.

The code, in most cases, stays exactly where it was.

Shopify doesn’t have a clean uninstall hook that walks back through every theme edit an app has made. App developers vary wildly in how thoroughly they clean up — some don’t clean up at all, some leave a comment block, some try and miss the dynamic injections their app made on the fly. The result is that a Shopify theme that’s been live for two or three years often has orphaned code from a dozen apps that aren’t even installed anymore.

You don’t see this in normal conditions. On a quiet Tuesday afternoon, with twenty visitors browsing at their own pace, an extra CSS file and three unused JavaScript libraries don’t cause a problem. Pages load. Carts add. Checkouts complete.

What changes when the sale starts

Campaign traffic makes the customer journey more important, but browser work happens per page view rather than because a file merely exists. The audit target is an active request, render, or execution path that evidence shows is no longer needed.

Most of this is invisible to the merchant. What you see is a Shopify store that felt fast on the dev side but is sluggish on mobile under load. What customers see is a homepage that takes a second longer to paint, a product page that hangs while a script blocks rendering, a cart that doesn’t quite open when they tap.

A slower experience can matter during a sale, but conversion changes have many causes. Use store-specific performance and analytics data rather than applying a generic revenue multiplier.

Why the usual fixes don’t catch this

A lot of pre-sale speed advice points at the same handful of moves: compress your images, switch to a lightweight theme, remove unused fonts, lazy-load anything below the fold. These are real and worth doing. But they sit in a different layer to the one I’m talking about.

A switched theme imports a fresh slate, true — but only if you rebuild every customisation from scratch. Most merchants migrate their existing customisations across, which brings the orphaned code with them. Compressing images doesn’t touch JavaScript at all. Removing unused fonts addresses one specific thing. None of them ask the harder question: which of the scripts loading right now belongs to an app I still have installed?

That question is hard to answer manually because file names, static references, dynamic Liquid, app history, and storefront behaviour all provide only part of the evidence. Start early enough to investigate instead of rushing a change before the sale.

The clean version of the workflow

We built ThemeSweep to organise that investigation. It scans supported theme text files, applies static-reference and known-signature analysis, and presents the location, evidence, confidence, and likely source for each candidate.

Shopify does not provide ThemeSweep an authoritative list of the merchant’s other installed apps. Dynamic references and customisations can also make static analysis uncertain. That is why ThemeSweep exposes confidence and evidence instead of treating a match as permission to delete.

Review remains mandatory. Selected code is revalidated before cleanup, changes are prepared on a duplicate theme, and file backups and rollback remain available for 30 days. Those safeguards reduce risk; they do not make an automated scanner infallible.

Scan duration depends on the theme. The output is a review list you can investigate yourself or hand to a developer together with the supporting evidence and uncertainty.

Where this fits in your pre-sale checklist

If you’re running a sale in the next few weeks, the order I’d suggest:

1. Two weeks before launch — inspect and review. Identify potential leftovers, verify active references, prepare any change on a duplicate, and test the storefront on desktop and mobile.
2. One week before launch — speed retest. Run Shopify’s speed score and a separate tool like Google PageSpeed Insights. You’re looking for a confirmed lift from the cleanup, not just hoping for one.
3. Three days before launch — test the critical pages. Homepage, top product page, cart, checkout. On mobile, on 3G, in a private window so you’re not getting cached results.
4. Day of launch — keep the diagnostic tools open. If something does start straining, you want to see it in the first hour, not in the post-mortem.

The cleanup step is the one that gets skipped most often because it’s the least obvious. It’s also the one that compounds across every other thing you’ve already done — a faster baseline makes every other optimisation more effective.

Worth saying

I ran a multi-site retail business for over two decades before building software full-time. I know what it feels like to spend weeks preparing for a big trading window and then watch something small undercut the whole thing. The version of this in physical retail was usually staffing or stock. The version of this in Shopify is usually code that nobody remembers installing.

The fix isn’t complicated. It just needs doing before, not after.

Learn how ThemeSweep works → www.themesweep.com. ThemeSweep is installed from its Shopify App Store listing.

Frequently asked questions

Why does Shopify leave code behind when I uninstall an app?

Shopify revokes the app’s access and app charge. Modern app blocks and app-owned resources may disappear cleanly, while direct theme edits or assets can remain. Inspect the current theme rather than assuming either outcome.

Does cleaning up dead code actually speed up a Shopify store?

It can, if the removed resource was still being requested, parsed, or executed. An unreferenced file may have no page-load cost. Measure the affected pages before and after instead of assuming a fixed improvement.

How long before my sale should I do a theme cleanup?

Two weeks is ideal. That gives you time to clean, retest, fix anything the retest surfaces, and do a final mobile check before the campaign goes live. Doing it the day before the sale leaves no buffer if something breaks during removal.

Will removing dead code break my store?

Not if you duplicate your live theme first. Go to Online Store → Themes, click the three-dot menu on your live theme, and choose Duplicate. That’s your rollback. If anything looks wrong after a removal, republish the duplicate and you’re back where you started within thirty seconds.

Related reading

• 5 Signs Your Shopify Theme Is Full of Dead App Code — How to confirm the problem is there before you start removing anything.
• The Hidden Cost of Uninstalling Shopify Apps — The full technical explanation of why code stays behind and what it costs.
• How to Remove Dead App Code from Your Shopify Theme (No Developer Needed) — Step-by-step manual removal guide.
• Shopify Theme Audit Tools Compared — How ThemeSweep stacks up against alternatives.

Related reading: 5 Signs of Dead App Code · Hidden Cost of Uninstalling · Remove Dead App Code (Manual Guide) · ThemeSweep.