No single change makes a storefront slow. It is the accumulated residue of three years of campaigns, trials and quick fixes — and unlike most debt, nobody sends you a statement.
Ask a store owner why their site is slower than it was two years ago and you will usually get a shrug and a guess about images. The real answer is almost always archaeological: layers of things added for a reason that has since expired, none of them ever removed.
How the layers form
- A campaign script for a sale that ended eighteen months ago, still loading on every page.
- Two apps trialled, uninstalled, and their theme snippets left behind because removal was manual and nobody was sure what would break.
- A third-party font added for a banner, now loading alongside the theme's own fonts.
- Tracking added in layers — one tag for ads, one for analytics, one for a heatmap tool that ran for a month.
- Fixes applied directly to the live theme during a busy week, never folded back into the real one.
Each was a small, reasonable decision. Collectively they are why the site takes another second to become usable, and why every future change is slower and riskier to make.
The second cost is worse than the first
Slow pages cost conversions, and that gets the attention. The bigger cost is that theme debt makes change expensive. When nobody can say what a snippet does or who added it, the safe move is to leave it, and add beside it. That is how debt compounds: the cost of the debt is more debt.
The symptom to watch for is not page speed. It is the sentence 'we'd rather not touch that.'
A cleanup that will not take the store down
- Work on a duplicate theme, never the live one. Obvious, routinely skipped under time pressure.
- Inventory before you delete. List every script, snippet and asset with what it does and who owns it. The unknowns are your worklist.
- Remove one thing at a time and publish between removals. A batch of ten changes that breaks something gives you ten suspects.
- Measure the same page, same device, same connection, before and after each removal. Otherwise you are collecting opinions.
- Write down what you removed and when. The next person — possibly you — needs to know this was deliberate.
Preventing the next three years of it
Debt accumulates because adding is easy and removing has no owner. Two habits fix most of it. First, anything added for a campaign gets a removal date written down at the same time it is added. Second, every app trial ends with a real uninstall check: did it actually leave, or did it leave residue? Apps that write into your theme should be held to a higher standard than apps that do not need to.
It is one of the reasons we built SellRank to stay out of the theme entirely. Sorting is computed server-side and written into Shopify's own manual collection order, so there is no snippet to leave behind and nothing to clean up later. When an app's footprint is zero, the uninstall question answers itself.
When it is genuinely time to rebuild
Cleanup has limits. If the theme is several major versions behind, if core layout has been customised so heavily that updates cannot be taken, or if nobody can make a change without a day of investigation, you are paying rebuild-level costs annually without getting a rebuild. That is the point at which redevelopment stops being a luxury and starts being the cheaper option.
That is a large part of what our client engagements look like: taking ownership of a storefront that grew feature by feature, and making it something the business can keep building on. It is less glamorous than a redesign and worth considerably more.
