Skip to content

Shopify Storefronts  ·  Speed and paid traffic

Why is my Shopify store so slow?

Four causes cover most slow Shopify stores: app scripts that load on every page, oversized images, too many font files, and years of accumulated theme code. Shopify's own hosting is rarely the problem. Diagnose on a phone over cellular, fix apps first, images second, and measure before and after each change.

Slow is expensive twice: buyers leave before the page paints, and the ad platforms charge you more to send traffic to a page they score as bad. The causes rank in a predictable order.

Cause one: app scripts

Every app you install earns the right to inject script on every page, and most take it whether the page uses the app or not. The review widget loads on the blog. The bundle app loads on the contact page. The abandoned-cart tool loads on a policy page nobody abandons a cart from.

Uninstalling helps less than founders expect, because many apps leave their code in the theme after removal. That is the sediment problem in cause four, arriving early.

Diagnosis: open your storefront with your browser’s network tab and count third-party domains. Ten or more you do not recognize is common and bad. Then cross-check against your app list and your billing. Most stores are paying for at least one app nobody has opened in a year, and it is still loading on every page view.

The fix: an app audit. Remove what you do not use, then have the leftover code stripped from the theme. This is the highest-return speed work on most stores and it usually costs less than a single section build, which runs $300 to $2,000 at the $50 to $150 hourly rates competent Shopify freelancers charge.

Cause two: images

Furniture-sized hero images shipped at 4,000 pixels wide for a phone screen. Product photos uploaded straight from the supplier at print resolution.

Shopify’s CDN resizes images when the theme asks correctly. Older themes and hand-edited ones often do not ask correctly, so the browser downloads the full-resolution file and shrinks it on the client, paying the full transfer cost for none of the benefit.

Diagnosis: if your largest homepage image weighs more than a few hundred kilobytes on your phone, the theme is not sizing responsively.

The fix: lives in the theme’s image rendering, not in manually shrinking uploads forever. Fix it once in the template and every future upload inherits the fix.

This is worth real attention for high-consideration catalogs. For one home brand I run, close to 80% of sessions are mobile, on furniture buyers want to see at room scale. The imagery has to be big enough to sell and small enough to arrive, and only the template can hold both.

Cause three: fonts

Each font family and weight is a file the browser must fetch before text settles. Themes configured with a display font, a body font, and five weights of each ship a wardrobe when the design needs an outfit.

Two families, two or three weights total, covers almost any brand and cuts font weight by half or more. This is a theme settings change on most modern themes, which puts it inside the founder’s own reach.

Cause four: the theme itself

Legacy themes and heavily patched ones carry years of sediment: sliders nobody uses, scripts from apps deleted in 2023, CSS for sections that no longer exist.

Past a point, cleanup inside the old theme costs more than moving to a current one. That threshold decision is covered in facelift or full rebuild.

What is almost never the cause

Shopify’s hosting. The platform serves fast globally, and switching plans will not fix a slow store. The weight you added is the weight you remove.

Two more false leads worth naming. A speed-optimizer app, which adds a script to fix a script problem. And a theme swap bought for speed alone, which moves your slow content into a fast frame and leaves you at roughly the same number.

Where speed sits in the build, and why that saves money

Speed work costs less inside a project than after one.

On my storefront builds, page speed is a build spec item measured before launch rather than a cleanup engagement later. A build that starts at $5,000 and ships in two to four weeks includes it. Bought as remediation afterward, the same work is a separate engagement, plus whatever the slow months cost in ad spend on pages the platforms were scoring down.

The pattern repeats with tracking, which is the other thing redesigns leave for later. Wired during the build it is part of the number. Bought afterward it is a $2,500 sprint on its own. The published cards are at /pricing.

The fix order and the measurement rule

Apps first, images second, fonts third, theme sediment last. That order is by return per hour, and it holds on almost every store I open.

Measure on a phone over cellular before the first change and after every change, using the same page each time. One variable, one measurement, or you will never know which change earned the improvement.

Measure your paid landing pages specifically, not your homepage. Speed there is priced into every click you buy, and the homepage is rarely where paid traffic lands. Which page paid traffic should land on is its own decision, covered at product page or landing page.

What to do this week

If you have never audited the apps, start there and nowhere else. Open the network tab, count the domains, match them to your app list and your invoice, and remove what nobody uses. Then have the residue stripped out of the theme, because uninstalling an app does not uninstall its code.

If the store is already lean and still slow, the problem is the theme’s age, and the honest fix is structural. When I build or facelift a storefront, speed ships inside the project rather than as a cleanup later, which is cheaper in both directions. The way that works is at /storefronts.

Want this diagnosed in your account?

Same diagnosis,
run on your account.

Thirty minutes on the phone. I look at your spend, your tracking, and your search-term reports before the call. You walk out with a clear list of what is leaking and what to fix first.