What actually slows down a Shopify store

The sequence is familiar. The speed score drops into the thirties, someone screenshots it, and the response is to start uninstalling apps.

Occasionally that helps. Usually it removes functionality the business was relying on and moves the score by a couple of points, because the apps were never the main problem.

The speed score is not the thing you’re trying to fix

Shopify’s online store speed score is a lab measurement — one simulated load of a handful of pages, on a fixed connection, in a fixed location. It’s useful as a rough signal and useless as a target.

What affects revenue is how quickly a real customer, on a real phone, on real mobile data, can see and interact with your page. Those numbers can move in opposite directions. We’ve seen stores improve materially for actual users while the score barely shifted, and stores chase the score into decisions that made the real experience worse.

If you’re going to watch one thing, watch field data — the real-user measurements in Google Search Console’s Core Web Vitals report. That’s what your customers experienced, and what search engines actually weigh.

The real cause is usually how the theme is built

Apps add weight. But most apps load a script and some CSS, and a well-built theme absorbs that without much trouble.

What doesn’t absorb it is a theme that has been worked on by a series of different developers over several years, each adding what they needed without removing what was no longer used. Every past campaign’s CSS is still loading. Scripts that supported a removed feature still request. Assets load in an order that blocks rendering rather than supporting it. Nothing individually is a disaster; collectively, the browser is doing a great deal of work before it can show anything.

This is the situation we found at Vegamour. Slow load times originating in inefficient development practices and unoptimised theme architecture — hurting the experience, hurting conversion, and putting a ceiling on what the brand could scale to.

The important constraint was that they didn’t want to rebuild. So the work was a performance audit to locate the actual bottlenecks, then restructuring how assets, scripts and code were being delivered — and going a level further into the theme architecture itself to cut unnecessary load. Significant speed and performance improvement within four months, with conversion rate and AOV both rising, because the CRO work was done alongside rather than after.

That last part matters. Speed on its own doesn’t convert anyone. It removes a reason to leave.

Speed becomes a different problem under load

A store that performs acceptably in February can fail in November, and the cause isn’t the same one.

TYR came to us before peak season with a large, heavily merchandised catalogue, unused code and inefficient assets slowing the site — and no appetite for risky changes with the busiest weeks approaching. The work was a focused sprint inside the existing environment: cleaning unused scripts, optimising assets for speed and stability under load, alongside restructured navigation and standardised product taxonomy so filtering actually held up at scale.

Peak-season revenue rose 25% year on year, with orders up 37%.

If your traffic is seasonal, test under load before the season, not during it. Average-day performance tells you very little about what happens when traffic multiplies.

What to look at, in order

1. Field data before lab data. Search Console → Core Web Vitals. Are real users failing, and on mobile or desktop?

2. Render-blocking resources. What has to finish downloading before anything appears? This is usually where the largest single gain is.

3. Image weight and format. Still the most common avoidable problem. Modern formats, correctly sized, lazy-loaded below the fold.

4. Scripts that no longer do anything. Every store that’s been running three years has them. Removing an app doesn’t always remove its code from the theme.

5. Third-party tags. Analytics, pixels, chat, reviews, personalisation. Each is defensible; together they can be the largest block of work on the page. Audit what’s actually being used by someone.

6. Theme architecture. The deepest and most valuable layer — how the theme loads what it loads. Requires a developer, and it’s where the durable gains are.

Three things worth knowing

• Don’t judge speed from your own machine. You’re on desktop broadband with everything cached. Test on a mid-range Android on mobile data.
• Don’t delete apps before checking whether they’re the cause. Measure first. Removing a review widget that was providing social proof to save 80ms is a net loss.
• Speed work decays. Six months of theme edits and new tags will erode it. Build a check into your quarterly routine rather than treating it as a project you complete.

A quick self-audit

• Open your Core Web Vitals report in Search Console. Note the mobile figures, not the desktop ones.
• Load your top-selling product page on a phone on mobile data. Count the seconds before you can tap “add to cart.”
• List every third-party script running on the store. Mark the ones nobody has looked at in six months.
• Check the file size of the largest image on your homepage.
• If you had a peak season last year, find out what your load times looked like during it.

If you want a specific answer

Speed problems are individual to the build. Generic advice gets you the first 20%; the rest is in your theme.

We record a free teardown — where the time is actually going on your store, what we’d fix first, and whether it can be done inside the existing theme. Back to you in 48 hours, no call required.