speed
Are Shopify apps slowing down your store? How to find out
Every speed audit I do in 2026 has the same finding: apps are the biggest thing slowing the store. Not the theme, not Shopify itself, not the customer’s network. Apps.
But “delete all your apps” is bad advice. Apps do real work — they handle reviews, upsells, shipping rules, retargeting, things that drive revenue. The question isn’t whether apps slow your store (they do), it’s which apps are worth what they cost in performance.
This post is the framework I use during audits to figure that out. You can run it yourself.
Sub-post of the Shopify Speed Optimization Guide.
How apps slow Shopify stores
Three mechanisms:
- JavaScript on every page. Each app that uses an “app block” or theme injection ships its own JS that runs on page load. Multiply by 15–25 apps and you have hundreds of KB of script competing for the main thread before the customer sees anything.
- Render-blocking app blocks above the fold. Modern themes let merchants drop app blocks into hero sections. Each block is a separate render — and if the block fetches data from the app’s server, your hero waits.
- Third-party DNS lookups + TLS handshakes. Each app that calls back to its own server (analytics, personalization, A/B test) requires DNS resolution + a new HTTPS connection. On mobile, this can add 200–500ms before any data even starts coming back.
The cumulative effect: a store with 20 apps loads roughly 2–4× slower than the same store with 5 apps, even if each app is “well-built”.
How to find which apps are the offenders
Three tools, in order of effort:
Method 1: PageSpeed Insights “Third-party” diagnostic (5 minutes)
Run PageSpeed Insights on your homepage (mobile). Scroll down to Diagnostics → “Reduce the impact of third-party code”.
You’ll see a table like:
| Third party | Main-thread blocking time |
|---|---|
tracking.somechatapp.com | 312 ms |
cdn.somereviewsapp.com | 187 ms |
googletagmanager.com | 95 ms |
| … |
Anything over 100ms is a candidate to investigate. Anything over 200ms is a confirmed offender.
Match the domain to your installed apps (the domain is usually the app’s name or the company behind it).
Method 2: Theme Inspector (10 minutes, slightly technical)
In your theme customizer, press Cmd+Option+I (Mac) or Ctrl+Alt+I (Windows) to open Shopify’s Theme Inspector. It overlays per-section render times.
Anything rendering over 50ms is suspicious. Over 200ms is broken. App blocks usually surface here as “block: someapp”.
Method 3: A/B test by disabling (30 minutes, the only definitive answer)
The most reliable test: temporarily disable the app, re-test PSI, see if the score moves.
For each suspect app:
- Note your current PSI mobile score and CrUX numbers.
- Disable the app (Apps → Installed → app → Settings → Disable, or uninstall if it’s a Liquid block you can confidently remove).
- Wait 5 minutes. Re-run PSI.
- If the score moves +5 points or more, that app is a real cost. If not, the app is fine.
- Re-enable.
This is more work but is the only honest answer. The diagnostics in methods 1 and 2 are suggestive, not definitive.
The framework: what to keep, what to cut
For each app, ask three questions:
1. Does this app drive revenue I can measure?
If you can’t point to either (a) a sales report attributing revenue to the app, or (b) a real operational benefit (shipping rules, inventory sync), the app is a candidate to remove.
Common candidates that fail this test on most stores:
- Apps installed during a previous era that nobody uses now
- “Free” apps installed because they were free, never configured
- Reviews apps when nobody’s asked customers to leave reviews in 18 months
- Personalization apps with default rules that haven’t been tuned
- Three different popup apps competing with each other
2. Does it earn its slot above the fold?
Some apps need to render above the fold (a price-display app, a free-shipping bar). Most don’t (a chat widget, a reviews summary, a recommendation carousel).
Apps that don’t earn their slot above the fold should be:
- Moved to a later section of the page
- Lazy-loaded (the app’s settings often have “load on scroll” or “load after delay”)
- Replaced with a native theme implementation if possible
3. Could a cheaper / simpler tool do this?
Some examples I see often:
- Currency converters — Shopify Markets does this natively. Drop the app.
- Free-shipping bar — most themes have a native announcement-bar section. Drop the app.
- Sticky add-to-cart — most modern themes ship this as a section setting. Drop the app.
- Image gallery / lightbox — natively in modern themes. Drop the app.
- Google Tag Manager — Shopify’s built-in customer events + native script tags often replace the GTM container entirely.
The general rule: if the app does something Shopify or your theme already does natively, the app is paying for an old gap that’s since been closed. Remove it.
Apps I rarely recommend cutting
Some apps are worth their performance cost on most stores:
- Klaviyo / your email/SMS app — revenue driver, the JS is mostly fine
- A reviews app you actively collect from — social proof matters
- An upsell app with a working configuration — if it lifts AOV measurably, keep it
- Shipping calculation / fulfillment apps — these are operational, no real alternative
- B2B / wholesale apps if you’re actually B2B
The pattern: keep apps with measurable revenue/operational impact. Cut apps that are “nice to have” or installed-and-forgotten.
What I’d do this week
A 90-minute exercise that consistently moves stores’ speed scores by 10–20 points:
- Inventory (10 min): export your app list (Apps → Installed). For each, note last login, last config change, and whether you can name the revenue/operational impact.
- Diagnose (20 min): run PSI mobile on home, collection, product. Note the third-party blocking time table.
- Cut the obvious (15 min): remove anything that fails question 1 above (no revenue, no operations). Pause first if you’re nervous; uninstall after a week if nothing breaks.
- Defer the survivors (30 min): for each remaining app, find its “delay load” or “show on scroll” or “lazy load” setting. Turn it on.
- Re-measure (15 min): re-run PSI on the same three pages. Note the new numbers.
I’ve never seen this exercise not improve a store’s CWV. The variance is in how much.
When to call a developer
If you’ve cut what you can and you’re still in “Poor” CWV, the issue is usually one of:
- An app that does something operationally critical but ships bad code
- An apps stack that’s interacting badly (one app’s JS triggers another)
- Theme-level rendering issues unrelated to apps
- Liquid loops that the apps’ merging make worse
That’s where a speed engagement earns its keep — someone who can read the code, identify which app is the actual offender, and either replace it, defer it, or work around it.
What I do in audits: look at your installed app list, your CrUX numbers, your DevTools waterfall, and your theme code, and produce a written one-pager: “keep these, drop these, defer these, replace these”. Most merchants find that exercise alone is worth the engagement.
Want me to look at your app stack? Book a free intro call. Pull up your Apps → Installed list before the call; we’ll go through it line by line and I’ll tell you which 3–5 are likely costing you the most performance and what to do about each.
Found this useful? Get in touch or subscribe to the RSS feed .