Skip to main content

Slow Shopify store: why your fixes aren't enough anymore

You've already compressed the images, removed apps, and switched themes, and the PageSpeed score is still orange. Why surface-level fixes plateau, and what actually solves the problem.

The short answer

A Shopify store stays slow after image compression and app removal when the problem is the theme itself: a generic theme loads unused code on every page, and each app adds its own script with no coordination with the others. Measure your Core Web Vitals (LCP, CLS, INP) on PageSpeed Insights and in the Search Console report to find out where the problem actually sits. Past a certain point, only a custom-built theme brings load time down for good.

Why is my Shopify store still slow when I've already tried everything?

You've compressed your images to WebP, uninstalled the apps you no longer needed, maybe switched themes last year. The PageSpeed Insights score is still orange on mobile, sometimes red. The store still takes three to four seconds to load. This isn't a discipline problem: you've done what the guides recommend. It's a diagnosis problem, not an execution one.

Most of the advice you find online targets visible symptoms (heavy images, too many apps, badly configured caching), not the cause when it runs deeper. On a store that's been touched up over the years by several different providers, those fixes buy you a few tenths of a second and then stop: the speed has sat in the same range for months.

Why do quick fixes plateau?

Compressing images and removing zombie apps works, up to a point. Every installed app loads its own script on every page, even the ones where it does nothing. Every theme section adds its own stylesheet. Every third-party script blocks rendering for a few hundred milliseconds.

Taken one at a time, each element looks harmless. The problem shows up in the pile-up: on a store running twelve to fifteen active apps, the total weight becomes unmanageable, and no amount of image compression fixes that. Cleaning up apps trims part of the real weight, but it assumes the underlying theme is sound to begin with.

The real culprit: the generic theme and the app pile-up, not your images

A Shopify theme, even a premium one, is built to work across thousands of different stores, with dozens of settings you can toggle on or off in the editor. That flexibility comes at a cost: conditional code everywhere, sections that are never used but still load, stylesheets that cover use cases your store will never need.

Add a dozen paid apps on top, each one injecting its own script with no coordination with the others, and the store downloads several megabytes of code before it even shows the first product. That's what turns up when auditing an existing store: rarely a single badly coded app or one oversized image, almost always a pile-up of layers that makes each isolated fix fall short. The full approach is covered in /guides/shopify-sans-applications-payantes.

How do you measure your Shopify store's speed yourself?

Two free tools are enough for a first diagnosis. PageSpeed Insights tests one specific page (not just the homepage: test a product page) and gives you a score plus three concrete measurements. The Core Web Vitals report in Search Console shows real data from your actual visitors, grouped by status: good, needs improvement, poor.

The three measurements that matter are the Core Web Vitals, a Google ranking signal since 2021. LCP measures how long it takes for the largest visible element to load, usually your product image. CLS measures layout shifts, like a button jumping right before you click it. INP measures the delay between a click and the page's reaction.

The exact thresholds are published by Google on web.dev, and reproduced in the table below. A store sitting in the orange or red on mobile loses visitors before any visual problem even becomes obvious: the slowness shows up first in the bounce rate, not in the page's design.

MeasurementGoodNeeds improvementPoor
LCP (load time)≤ 2.5 s2.5 to 4 s> 4 s
INP (responsiveness)≤ 200 ms200 to 500 ms> 500 ms
CLS (visual stability)≤ 0.10.1 to 0.25> 0.25

What can be fixed without rebuilding the whole store

Some fixes still pay off even on a store built on a generic theme, and none of them require touching the code. Here are the ones that bring a real, measurable gain without a rebuild, in the order they're usually applied, before considering anything heavier or more costly.

  • Compress and resize images to their real display size. A 4,000-pixel product photo uploaded straight from the shoot is still the cheapest fix available.
  • Remove unused apps and check what they leave behind. Uninstalling an app doesn't always remove the code it injected into the theme.
  • Merge features that overlap. Reviews, a stock counter, a pop-up: each of these apps loads its own script; keeping just one that covers all three already cuts the weight.
  • Defer non-essential scripts. Live chat and extra ad pixels can often load after the initial page render, with no functional loss.

What actually requires rebuilding the theme

If the JavaScript weight loaded before the page renders is still high after that cleanup, the theme itself is the problem, not the apps. A generic theme customized over several years, with sections added and settings never removed, loads code your store no longer uses but that the editor still keeps active.

The only lasting fix is a theme written for a single store, with Liquid code that only loads what each page actually needs: no ghost sections, no stylesheet for a disabled feature, no dependency on an app just to show a customer review. It's not an aesthetic choice, it's a speed choice.

That doesn't mean banning every app: payment or logistics have no reasonable custom-code alternative. The question to ask app by app is more precise: could a few dozen lines of code cover this feature without an external dependency? If so, every app removed is a permanent gain.

What it actually changes: two rebuilt Shopify stores

On Pimo Care, a bilingual France/Switzerland store delivered in six weeks, mobile LCP dropped by 1.8 seconds after the rebuild: not a settings tweak, a full reconstruction of the product and collection pages, built to load only what matters for the initial render. Details are on /realisations/pimo-care.

On Grillé, the store now runs twice as fast as before, and around €200 in app subscriptions were removed by replacing them with code written directly into the theme. The business result, 3x sales compared to the old site, is detailed on /realisations/grille. Two stores, two different starting points, the same principle: speed gets built into the theme, it doesn't get bolted on afterward.

What should you do now?

Two paths open up. The first: keep treating symptoms (one more compressed image, one more uninstalled app) while accepting that the gains will stay marginal if the theme is the real problem. The second: have the theme and the apps audited together, to find out whether a custom rebuild is justified.

Both options are legitimate depending on where your store actually stands. What isn't legitimate is repeating the same surface fix for six months and expecting a different result. At Sonho, a custom Shopify rebuild runs between €8,000 and €25,000 HT, with a 6 to 10 week timeline. Get in touch for an audit that will tell you honestly where the problem comes from.

Frequently asked questions

Is compressing my images enough to fix a slow Shopify store?
It's often enough when the problem genuinely comes from oversized images: that's the most common cause on newer stores. A 4,000-pixel product photo displayed at 800 pixels wide carries hundreds of kilobytes it doesn't need, and compressing it to WebP remains the cheapest fix available. But if your theme loads unused code on every page and your store runs on a dozen active apps, image compression brings a limited gain, often a few tenths of a second, that doesn't address the underlying cause. The right move is to measure before you fix: open PageSpeed Insights and check the weight of the JavaScript loaded before the first product renders. If it's still high after that cleanup, the problem is structural, not visual, and only a theme rebuild solves it for good.
How do I know if the problem is the theme or the apps?
Open Chrome DevTools, go to the Network tab, reload a product page, and check the total weight of the JavaScript loaded before the page renders. If that weight stays high after uninstalling the apps you don't need, the theme itself is probably the culprit: a generic theme, customized over several years by different providers, often loads code for sections or settings your store no longer uses. Second, simple check: compare the Core Web Vitals report in Search Console before and after removing apps. If mobile LCP barely moves, the cause isn't in the apps you removed. Both checks are free and give you, in ten minutes, a more reliable answer than a generic audit bought online, telling you whether to keep cleaning up or move to a theme rebuild.
What are LCP, CLS, and INP?
These are the three Core Web Vitals, the measurements Google uses to evaluate the real experience of your visitors, a ranking signal since 2021. LCP (Largest Contentful Paint) measures how long it takes for the largest visible element to load, usually your product image: a good score is 2.5 seconds or less. CLS (Cumulative Layout Shift) measures layout jumps, like a button shifting right before you click it: a good score stays under 0.1. INP (Interaction to Next Paint) measures the delay between a click and the page's visible reaction: a good score is 200 milliseconds or less. All three can be measured for free on PageSpeed Insights or in the Core Web Vitals report in Search Console, using real data from your actual visitors rather than a lab test.
Do you need to remove all your Shopify apps to go faster?
No. Some apps cover real needs with no simple custom-code alternative, like payment or logistics: removing them would break more than it would fix. The question to ask app by app is more precise: could this feature be covered by a few dozen lines of code written directly into the theme, with no external dependency? A stock counter or a simple review carousel are typically features a whole app doesn't need to carry. On the other hand, a split-payment module or a logistics connector fully justifies its script. So the sorting happens feature by feature, not by app count: a store with five well-chosen essential apps is faster than a store with two apps if one of them duplicates something the theme could handle on its own.
How much does a Shopify rebuild cost to fix a structural speed problem?
At Sonho, a custom Shopify rebuild runs between €8,000 and €25,000 HT depending on the complexity of the catalog and the features to carry over, with an average timeline of 6 to 10 weeks. That figure is only given after a discovery call that assesses the real state of the theme and the apps in place: a store with ten active apps and three years of customizations doesn't start from the same place as a recent, well-kept one. On Pimo Care, this kind of rebuild brought mobile LCP down by 1.8 seconds. On Grillé, the store now runs twice as fast, with around €200 in app subscriptions removed along the way. The scope covers a full rebuild of the theme, section by section, not a surface cleanup that just pushes the problem down the road.
Sonho

A first call to talk through your project, no strings attached.

The first call is about understanding your project. You get a price range, a realistic timeline and our honest take on feasibility. If we're not the right fit, we'll point you to someone who is.

Twenty-plus projects delivered, on time every time.

GrilléBleu Mon JulesYade Paris
20+ brands trust us