The Speed Tax: What One Extra Second Costs A Shopify Store, In Real Money

The Speed Tax: What One Extra Second Costs A Shopify Store, In Real Money

I’ve sat through a lot of meetings where someone presents a Lighthouse score. There’s a red circle with a number in it, everybody looks slightly guilty, a ticket gets raised, and nothing meaningful happens. The score is treated as a grade — something you’re supposed to feel bad about — rather than as a proxy for a revenue line.

So let’s do it the other way round. Let’s put the number in pounds first, and only then talk about what to fix.

Turning milliseconds into money

The performance research most widely cited in ecommerce converges on a few figures. A **1-second delay in page response is associated with roughly a 7% drop in conversions**. At finer resolution, roughly **1% conversion decline per 100ms** of added load time. Sites with **Largest Contentful Paint under 2.5 seconds convert around 23% better** than sites over 4 seconds.

On bounce, the Google/SOASTA analysis that everyone quotes found bounce probability rising around **32% as load time goes from 1 to 3 seconds**, and around **90%** going from 1 to 5 seconds.

Standard caveat, and I’d rather give it than have you discover it: these are correlations across large site populations, not controlled experiments on your store, and several have been republished so widely that the original methodology has worn away. Trace them before putting one in a board deck. They’re directionally reliable and they’re not a physical law.

Now do the arithmetic on your own store, which is the only version that will change anyone’s mind.

Take your monthly sessions, your conversion rate and your average order value. Say 60,000 sessions, 1.8% conversion, £72 AOV. That’s 1,080 orders and about £77,760 a month.

Apply the 7%-per-second figure. If your LCP is 4.2 seconds and you get it to 2.4 — call it 1.8 seconds saved — you’re modelling roughly a 12.6% conversion improvement. That’s 1,216 orders, about £87,552. **Just under £10,000 a month.**

Do not present that as a forecast. Present it as the size of the prize, which is what it is. It’s the number that gets the work prioritised, and prioritisation is the actual bottleneck here — not knowledge.

The three metrics that matter

Forget the composite score. Three thresholds, all published by Google:

**Largest Contentful Paint (LCP) — good is under 2.5 seconds.** How long until the main content appears. On a product page this is almost always your hero image. It’s the metric with the clearest commercial link and usually the easiest to move.

**Interaction to Next Paint (INP) — good is under 200ms.** How quickly the page responds when someone taps. This is the one that makes a store feel cheap. A shopper taps “add to cart”, nothing happens for 400ms, they tap again, and now you have a support ticket about duplicate items.

**Cumulative Layout Shift (CLS) — good is under 0.1.** How much the page jumps around while loading. The direct revenue mechanism is mis-taps, and mis-taps on a checkout button are expensive.

Field data from real users is what counts, not lab scores. Reported Core Web Vitals pass rates sit around **42% on mobile and 63% on desktop** — mobile being where most of your traffic and nearly all of your problem is.

Where Shopify stores actually lose time

Having looked at a lot of these, the causes are boringly consistent.

**Apps.** By a distance the biggest offender. Every app that injects a script into your theme costs you. Reviews, upsells, popups, loyalty, wishlist, currency converters, chat widgets, analytics, heatmaps, three separate pixels. Each one seemed worth it individually. Collectively they’re often 60–70% of your JavaScript.

The killer is uninstalled apps. Removing an app from your admin does not reliably remove its code from your theme. I’ve found leftover script tags from apps uninstalled two years earlier, still loading, still blocking, still being paid for in conversion rate.

**Images.** Usually the LCP element. Oversized hero images, no WebP, no responsive sizing, no lazy loading below the fold, and product galleries loading twelve full-resolution shots when one is visible.

**Theme bloat.** Themes accumulate. Sections built for a campaign in 2023, custom Liquid from a developer who left, three font families where two are used, a slider library loading on pages with no slider.

**Third-party scripts.** Tag manager containers full of tags nobody can account for. Chat widgets loading their whole runtime on first paint. Fonts served from external domains with no preconnect.

The app audit nobody wants to run

This is the highest-value hour and the one that meets the most resistance, because every app has an internal advocate.

List every installed app. For each: what it does, what it costs monthly, and when anyone last looked at its impact. Then view source on a product page and search for script tags — you’re looking for the ones you can’t account for.

Then ask the uncomfortable question per app: if this were £40 a month *and* 200ms of LCP, would we still buy it?

Some will survive that easily. Reviews, for most stores, earn their place. Some won’t, and you’ll find you’re paying twice for something nobody has opened in eight months.

For apps you keep, check whether they can be loaded conditionally — a product-page app has no business loading on your blog.

What to ignore

**Your Lighthouse score.** It’s a lab simulation on a throttled connection. Useful for spotting regressions, useless as a target. Optimise field data.

**Chasing 100.** The gap between 70 and 90 on a Shopify store usually costs a great deal for very little user-perceived difference. The gap between 30 and 70 is where the money is.

**Advice written for static sites.** You cannot ship a Shopify store with no JavaScript. Half the performance content online implicitly assumes a hand-built site with no commerce platform underneath it.

A two-week plan

**Week one, diagnosis.** Pull field data for your three key page types — home, collection, product. Run the app audit. Identify your LCP element on each template. Find orphaned scripts from removed apps. Establish baseline conversion rate by device.

**Week two, execution.** Remove orphaned scripts. Remove or replace the two worst-offending apps. Compress and convert the LCP image on each template and set explicit dimensions to kill layout shift. Lazy-load everything below the fold. Preconnect to your font and CDN origins. Defer non-critical third-party scripts.

Then leave it alone for four weeks, because Core Web Vitals field data is a 28-day rolling window and you will read noise as signal if you check it daily.

After four weeks, compare conversion rate by device against your baseline. Be honest about seasonality and anything else that changed.

The bit that connects to everything else

There’s a second-order argument I’d have found unconvincing two years ago and now think is real. Crawlers have budgets. A store that’s slow to render and heavy to fetch gets crawled less thoroughly, and a product page that isn’t fetched cleanly is a product page whose data doesn’t make it into the systems that decide what to recommend.

I wouldn’t optimise speed *for* that reason alone. But when the direct conversion case is already worth five figures a month on a mid-sized store, the fact that it also makes your catalogue easier for machines to read is a decent bonus for work you should be doing anyway.

*Sources: Google/web.dev Core Web Vitals thresholds; Google/SOASTA bounce probability research; aggregated performance and conversion analyses. Verify each figure against its original study before external citation.*