Nothing changed, but it got slower
The store was quick when it launched. Since then there has been a sale banner, a size guide pop-up, a reviews widget, a new mega menu, a loyalty app that was later removed, and several rounds of changes by different freelancers. Nobody made the store slow on purpose. It just feels heavier every year, especially on phones.
You have probably been told to compress images, and you did. It helped a little. The store still feels sluggish, and editing it has become risky because nobody is sure what each bit of code does.
Where the weight comes from
In a theme that has been edited for years, the slowness is rarely one thing. It is layers.
- Code left behind by uninstalled apps, still loading scripts or styles on every page.
- Several versions of the same library, loaded by different additions.
- Sections duplicated rather than edited, so old and new versions both ship.
- Tracking tags added for campaigns that ended long ago.
- Theme files edited directly, which is why the theme was never updated to a newer version.
That last point matters. A theme that has been edited by hand cannot easily take updates from its developer, so it misses performance improvements, and the gap with a current theme widens every year.
What a slow, tangled theme costs
| Cost | What you notice |
|---|---|
| Mobile visitors leaving | Higher bounce on product pages, especially from ads |
| Search visibility | Poor page experience scores in Search Console |
| Paid traffic wasted | Clicks that never see the page load |
| Fear of changes | Simple edits break other things |
| Slow campaigns | New landing pages need a developer every time |
The fear of change is the one owners mention most. When every edit might break something, the store stops being improved.
How we deal with an old, slow theme
- Measure on real conditions. We test key pages on mid-range phones and mobile connections, and read the field data Google reports, not just a desktop score.
- List everything that loads. Every script, style and app block on each template, with where it came from and whether anything still uses it.
- Find the dead code. Leftovers from removed apps, unused sections and duplicate libraries are identified and tested for removal on a copy of the theme.
- Decide: clean or rebuild. If the theme is fundamentally sound, we clean it. If it has been edited so heavily that it cannot take updates, we recommend moving to a current Online Store 2.0 theme and rebuilding your custom features properly as sections and app blocks.
- Rebuild custom features cleanly. Things you genuinely need, like the size guide or a special product layout, are rebuilt as editable sections rather than hard-coded edits.
- Put a guard in place. A simple performance check runs after changes, so weight creeping back is noticed early.
We tell you which route we recommend and why. A rebuild is not always the answer, and when a clean-up will do, we say so.
What you end up with
Before any of this goes live, we compare the old and new versions page by page, so you can see what changed in load time on the pages that matter to you, measured the same way before and after.
A store that loads quickly on the phones your customers use. A theme you can update, with custom features as sections your team can move and edit without a developer. A list of what loads and why, so the next app or tag is a decision rather than an accident.
Most of all, the team can make changes again without holding their breath.
Does your store fit this picture?
- The store has been live for years and edited by several people.
- It has got slower even though you compressed the images.
- You have uninstalled apps but are not sure their code went with them.
- Your theme cannot be updated because of custom edits.
- Small changes need a developer and sometimes break other things.