Deleting Shopify Apps to Speed Up Your Load Times

A ready-to-wear brand comes to us with a slow site. Really slow. 35 out of 100 on mobile in PageSpeed Insights, 57 on desktop. To give you a sense of scale, anything under 50 on mobile means you're deep in the red. Google tells you so, customers feel it, and your conversion rate takes a hit without you understanding why.

We dig in. And the diagnosis is always the same. A pile of installed apps, half of which nobody actually uses anymore. An A/B testing tool that costs a fortune and barely gets touched. Stuff installed two years ago for a one-off need and never removed. Every app is extra code that loads on every single visit. The result, the site crawls.

I'm going to walk you through how we look at this kind of case, why apps hurt your performance so much, and how we move over to a site that runs without them.

Why your apps are really slowing down your site

A Shopify app isn't magic. It's code that bolts onto your theme. Either a script or a block that gets injected into your pages. And that code has to be downloaded and executed by the browser every time someone lands on your site.

Multiply that by fifteen apps, and your browser has to load fifteen extra layers of code before it can even display your page. The heaviest ones are the usual suspects. Reviews, pop-ups, chats, upsells, currency selectors. Each one adds its little bit of weight. Stacked together, that's the difference between a site that loads in 2 seconds and one that loads in 6.

At a 6-second load time in eCom, you've already lost half your visitors. Customers don't wait. They leave.

And uninstalling an app isn't always enough to clean up the code behind it. A lot of them leave residue in the theme. Bits of script that keep loading even though the app is gone. So even after the cleanup, you have to go check the code to make sure everything's actually gone.

Going native instead of pruning app by app

Sorting through your apps one by one is a first step. You kill what you no longer use, you keep what's genuinely useful. But you're still stuck in the same logic, stacking external tools on top of your store.

On this kind of case, we go further. We start from a theme built to need zero apps. Every feature people usually hand off to apps, we develop natively, right inside the site's code.

What does that look like in practice.

The wishlist, the review system, the cart options and bundles, quick views, all of it gets coded in-house inside the theme. Everything that used to cost you a monthly subscription per app is now hard-coded into your theme, with no external dependency.

The benefits are simple. The code is lighter, so it loads faster, and you're not paying ten monthly subscriptions anymore. Bonus, you control your code instead of being at the mercy of a third-party vendor's updates.

We do a lot of custom work precisely for this, avoiding fifty thousand apps on the store and pushing performance to the max. That said, you have to weigh it up. If it means building something that takes five days to replace a $20-a-month app, it's not always worth it. Every case gets its own call. But on a site crawling at 35 out of 100, the math is quick.

If you want to dig into the logic of a cleanly built theme, I also cover it in this article on the Shopify product page.

How we test as we go

One important thing when you rebuild a lightweight theme is not to discover the result at the very end. You test speed with every new section you add.

You add a block, you measure. If the score drops, you know right away it's that section that's weighing you down. That way you can rework it before stacking the next one on top. It's much cleaner than building everything in one go and discovering at the end that you've dropped back to 40 out of 100 with no idea where it came from.

For measuring, one thing to keep in mind. Tools like PageSpeed Insights are variable. Run the test three times in a row and you'll get three slightly different scores. That's normal. So you test several times, you look at the trend, not the exact number from one isolated run. What matters is whether you're broadly at 80 or broadly at 40.

Before you rebuild, audit what's already there

To know what to replace, you first need to know what you have. And the most effective move here is to plug into the code repository. GitHub, where your code is stored.

That lets you pull every current feature on the site. You lay them all out, and across from each one you list what you can replace with native code. The wishlist, the review app, the upsells, you look at each one to see if you can rebuild it in-house. The one you can't easily replace and that's critical, you keep it but you keep it tight. Payment or fulfillment apps for example, you don't remove them, but you check they're not loading more than necessary.

And here's a point the brand's founder raised well, and he was right. The audit isn't purely technical.

When you take your site back in hand, you also look at your button wording. Does your CTA say "order" or "buy." Is your copy well placed. Does the journey hold up. No app will tell you that. It's common sense, experience and strategy. A fast site with bad CTAs still converts poorly. So you work both at the same time.

If you want to see what this kind of end-to-end support looks like, that's what we do in outsourced eCommerce management on Shopify.

Keeping it from creeping back

The real trap isn't the one-off cleanup. It's six months later, when the apps come back.

Because six months down the line, someone on the team has a need, installs an app to move fast, and you start stacking again. So you need one simple rule. Before installing anything, you ask whether it can be done natively. And you clean house regularly, say once a quarter, to cut what no longer serves a purpose.

On one of the accounts we manage, I ran a big review of the installed apps with the team, just to check there was nothing useless. Cost first, because cutting pointless subscriptions is margin recovered. Performance second. Just by cutting the dead apps, you've already gained something.

Speed is something you work on continuously. Something to monitor like inventory or cash flow. You measure, you cut what weighs you down, you replace with native code when it's worth it, and you make sure nobody reinstalls the heavy stuff behind your back. A site at 80 out of 100 that falls back to 50 in a year is just a site nobody took care of.