Why Your Shopify Store Is Slow (It's Probably the Apps)
Quick answer: Most slow Shopify stores aren’t slow because of Shopify. They’re slow because of accumulated app JavaScript, multi-megabyte images, and theme code that blocks rendering. The apps alone routinely add 1–3 seconds to mobile load time, and uninstalling an app often doesn’t remove its code.
You picked a fast theme. Shopify runs on serious infrastructure. So why does your store take five seconds to show a product photo on a phone?
Because of everything that got added after launch. Here’s where the time actually goes, in the order we usually find it.
1. The app graveyard
Every app you’ve ever tried (reviews, upsells, popups, wishlist, countdown timers, that “exit intent” thing from 2023) injected JavaScript into your theme. Many of them leave it there even after you uninstall, because Shopify apps commonly edit theme files and nobody cleans up.
On a typical audit we find 15–30 third-party scripts loading before the first product image. Each one is a network request, a parse, and a chunk of main-thread time on a phone that’s far slower than your laptop.
What works: a script inventory. Which apps still earn their keep? Strip the dead ones out of the theme by hand, defer the survivors so they load after the content, and self-host what’s left where possible.
2. Images doing cardio
A 4,000-pixel-wide hero image, exported straight from Figma at 3.8 MB, displayed at 390 pixels wide on an iPhone. We see it weekly.
Shopify’s CDN can resize and convert images on the fly. Most themes just don’t ask it to. Proper
srcset sizes, modern formats (WebP/AVIF), and lazy-loading below-the-fold images typically cut
total page weight by half or more.
3. Theme debt
Themes accumulate the same way apps do. Old sections you no longer use, three sliders’ worth of CSS, jQuery loaded because one snippet from a forum needed it in 2021. All of it ships to every visitor, on every page, before render.
The fix is unglamorous: remove what’s unused, split what’s page-specific, and inline the small critical CSS so the first paint doesn’t wait on a stylesheet round trip.
4. Tap lag (the INP problem)
Since 2024, Google’s responsiveness metric is INP: how long the page takes to react when someone taps. Heavy JavaScript keeps the main thread busy, so “Add to cart” does nothing for half a second. Shoppers tap again. Sometimes it adds two. Sometimes they just leave.
If your INP is over 200ms, your store feels broken on phones regardless of how fast it loads. We wrote more about this in INP: the silent checkout killer.
5. The jumping page (CLS)
The page loads, the customer goes to tap a product, and an announcement bar pushes everything down, so they tap a cookie banner instead. That’s layout shift, Google measures it (CLS), and it’s almost always caused by images without dimensions and late-loading banners or embeds.
What’s actually worth fixing first
| Fix | Effort | Typical impact |
|---|---|---|
| Remove/defer dead app scripts | Medium | −1.0 to −3.0s LCP |
| Image sizing + modern formats | Low | −0.5 to −2.0s LCP, −50% weight |
| Critical CSS / defer theme JS | Medium | −0.4 to −1.5s LCP |
| Main-thread cleanup | Medium | INP back under 200ms |
| Dimension every image/banner | Low | CLS to ~0 |
Start at the top. The app cleanup alone usually moves a failing store to “needs improvement,” and the first three together are what flips Core Web Vitals green.
FAQ
Does a faster theme fix this? Rarely. A theme swap without an app cleanup carries the same scripts into the new theme, and now you have a redesign project too.
Will Shopify’s own speed score tell me this? Shopify’s admin speed score is a rough lab number. Google ranks you on field data, what real visitors experience. That’s the number worth managing, and you can see it free in PageSpeed Insights.
How fast is fast enough? Google’s bar: main content visible under 2.5s, taps answered under 200ms, no visible layout shift, at the 75th percentile of your real visitors. Under that, you’re leaving money with your slowest half.