"I think one of my apps is slowing my store down, but I don't know which one." I hear some version of this on most of my audit calls. Sometimes it's a store that got noticeably slower after a recent install. Sometimes it's a store that's been getting heavier for two years and nobody can point to the moment it went wrong.

Either way, the usual advice you'll find online is useless here. "You have too many apps" doesn't help when you need to know which specific app to deal with. So let me show you how I actually find it, because it's more straightforward than most people expect, and you can do the first part without any code at all.

Step one: let PageSpeed name the culprit for you

Run your store's homepage and a product page through Google PageSpeed Insights. Ignore the big number at the top for now. Scroll down to the diagnostics and find the entry called "reduce the impact of third-party code." Expand it.

That table is the whole game. It lists every external script running on your page, grouped by source, with two columns that matter: the transfer size and the main-thread blocking time. Your apps show up here by name or by their script domain. A review app, a chat widget, a popup tool, each one is a row. Sort by blocking time and look at the top.

Most of the time the answer is sitting right there. One or two rows are dramatically bigger than everything else. That's your suspect. I rarely find a store where the slowdown is spread evenly across ten apps. It's almost always concentrated.

🔍
What a heavy app looks like in the table If one source is loading 300KB or more, or blocking the main thread for several hundred milliseconds, that's not normal background noise. That's an app holding your page hostage while it loads. Note the name and move to step two.

Step two: prove it without uninstalling anything

Here's the part most people don't know about. You don't have to uninstall an app to find out what your store would feel like without it. Your browser can pretend the app isn't there.

Open your store in Chrome, right click, choose Inspect, and go to the Network tab. Reload the page and you'll see every file your store loads. Find the requests coming from your suspect app's domain. Right click one and choose "Block request domain." Now reload again. The app is still installed, but its script is gone for this test, and you can see and feel the difference immediately.

If the page suddenly renders faster and the layout stops jumping around, you've confirmed it. If nothing really changes, that app wasn't your problem and you move on to the next suspect. This is the same logic a doctor uses with an elimination diet. Remove one thing, watch what happens, put it back, try the next.

Step three: measure it properly

Feeling faster is a good signal, but you want a number. The mistake I see people make is running PageSpeed once before and once after, then treating a 4-point difference as proof. Scores bounce. The same page tested three times in a row can swing by 5 to 10 points for reasons that have nothing to do with your store.

So do it like this if you want a result you can trust:

  1. Pick one page and stick with it. The homepage or a busy product page is fine. Test the same URL throughout.
  2. Test on mobile, throttled, in an incognito window so your browser extensions don't interfere.
  3. Run it three times and take the middle result, not the best one.
  4. Disable the suspect app, in a duplicated theme so your live store is untouched, and repeat the same three runs on the same page.
  5. Compare the medians. A real culprit moves the score by a clear margin, often 8 to 15 points on its own, not by 2 or 3.

Working in a theme copy is the safe way to do step four. You duplicate the theme, disable the app there, test against the preview, and your live store never changes while you experiment. If you're not comfortable doing that, the browser blocking trick in step two gets you most of the confidence without any risk at all.

Don't want to do the detective work?

I'll run the whole diagnosis for you and tell you exactly which app is the problem. Free audit, before we even talk.

Get a free speed audit →

The app you already removed might still be there

There's one case that trips up almost everyone. You test, you find the app, you uninstall it, you re-run PageSpeed, and the score barely moves. So you assume you were wrong. You weren't.

When you uninstall a Shopify app, Shopify removes the app from your account, but it does not always remove the code that app injected into your theme. Script tags, Liquid snippets, leftover asset files, they can all stay behind and keep loading as if nothing happened. I open theme files on audits and regularly find code from three or four apps the merchant swears they removed months ago.

This is why a store can stay slow after a clean-looking uninstall. The app count in your admin went down. The actual code running in your customer's browser did not. Finding and removing that leftover code is the part that usually needs theme access and a bit of care, because you have to be sure you're deleting the right lines.

Once you've found it

Finding the app is the win. What you do next depends on whether you need it. If it's an app you genuinely use, the fix is usually configuration, not deletion. Check its settings for an option to load only on the pages where it's actually used. Plenty of apps can do this and ship with it turned off, which is how a reviews app ends up loading on your blog.

If it's an app you forgot you had, remove it, then check the theme for the code it left behind. And if you've done the detective work and you're staring at leftover scripts you're not confident enough to touch, that's exactly the point where it makes sense to hand it over. I do this all day, in a preview theme, with a before-and-after report so you can see precisely what changed and what it did to your score.

Let me find the culprit for you

A free 20-minute call. I audit your store first and come in already knowing which app is costing you.

Book free audit →