Measuring what each Shopify app really costs your site speed
Keith Pillay · 29 September 2026 · 3 min read
Ask a store owner why their site is slow and the honest answer is usually "apps". Ask which app, and nobody knows. That's the gap this method fills.
Why apps are hard to judge
An app might add JavaScript, CSS, tracking calls and extra network requests to every page, including pages where it does nothing. Some load a lot upfront and do little. Some do a lot and load efficiently. You can't tell from the app's name or its reviews.
Apps are also invisible costs. Nobody sees the 200 KB script that a "free" review widget added to every product page.
The method
1. Work on a copy. Duplicate the theme so you never experiment on the live store.
2. Fix the test conditions. Pick three pages (home, a typical collection, a typical product page), one device profile and one network profile, and use the same ones throughout. Consistency matters more than which values you pick.
3. Get a baseline. Test each page several times and record the median. One run is noise.
4. Inventory what's installed. List every app, and for each one, where it injects code: an app embed in the theme editor, a script added by hand to the theme, a tracking snippet, or something loaded by a tag manager. Leftover code from uninstalled apps is common too, so search the theme for old snippets and script tags.
5. Remove one at a time. In the theme editor, switch off an app's embed on the copy, or comment out its snippet, and re-measure. Record the change in the metrics you care about (load time of the main content, total blocking time, request count, transferred bytes).
6. Rank by cost. The result is a table: app, what it does, what it costs in each metric, and whether you'd notice if it vanished.
What to look at beyond the score
The waterfall tells you the kind of cost:
- Download size. Large scripts hurt on slow phones.
- Blocking work. A script that monopolises the main thread delays everything.
- Third-party requests. Each extra domain has connection overhead, and each is a dependency you don't control.
- Layout shifts. Banners, widgets and badges that appear late push content around.
- Timing. Some apps do real work only after interaction, which a simple load test understates.
Making the decision
For each app, ask:
- What does it earn? Does it clearly drive revenue, trust or an operational need?
- What does it cost? From your measurements.
- Can the same thing be done cheaper? Native theme features, a lighter alternative, or a small custom section often replace a heavy app.
- Can it load smarter? Some apps can be restricted to the pages where they're needed.
Often the answer isn't "remove everything". It's removing the three apps nobody uses, replacing one heavy widget with a native feature, and leaving the rest alone because they pay for themselves.
Be honest about trade-offs
When an app change is needed, I give the client the numbers and the trade-off and let them decide. Removing an app that a team relies on for something I can't see is a business decision, not a technical one.
I also re-test the key flows afterwards: navigation, product page, add to cart, checkout. A faster store that can't take payments is a worse store.
A simple table to keep
| App | Where it loads | Cost (LCP / blocking / bytes) | Value | Decision | |---|---|---|---|---| | Reviews widget | Product pages | measured | Trust | Keep, load later | | Old popup app | All pages | measured | Unused | Remove |
Keep it updated. Apps get added; speed erodes slowly, and the table is how you notice.
This is the method behind step one of Seven things I check first when a Shopify theme is slow.
