Your mobile site loads 3.4x slower than your desktop site.

By Rob Sutcliffe
Published April 6, 2026

Your Shopify store probably has a decent desktop Lighthouse score. Maybe it’s in the 70s or 80s. You check it once in a while, feel reasonably good about it, and move on.

Then you test on mobile. The score drops to the 20s or 30s. The page takes 6–9 seconds to become usable.

You try it on your own phone, and it feels fine because you’re on WiFi, with a cached version, on a recent device, with a decent CPU. Your customers are not.

This is the gap that’s quietly bleeding revenue from the majority of Shopify stores I audit.

Desktop scores give you a number that looks acceptable. Mobile scores tell you what your customers actually experience. And those two numbers are telling very different stories.

The Gap Is Worse Than You Think

The global average desktop page load time in 2026 is around 2.5 seconds. On mobile, it’s 8.6 seconds. That’s 3.4 times slower, on the channel carrying over 58% of all e-commerce traffic.

For many Shopify stores, mobile is closer to 70%.

Meanwhile, user expectations have moved in the opposite direction. Akamai’s 2026 State of the Internet report found that 68% of mobile users now consider anything over 2 seconds “unacceptably slow.”

The average mobile site takes 8.6 seconds to load, and most users draw the line at 2. That’s not a gap. That’s a canyon.

When I audited 100 slow Shopify stores, the average mobile Lighthouse score was 31 out of 100—regularly 20–40 points lower than the desktop scores for the same stores. Owners almost always quoted the desktop number when asked about their site speed, often unaware of their mobile score.

Why Your Desktop Score Lies to You

Lighthouse desktop and mobile tests don’t just differ in screen size. They simulate completely different conditions.

The desktop test uses a fast, unthrottled connection and a powerful CPU. The mobile test throttles the network to simulate mid-tier 4G and slows the CPU by 4x.

This setup approximates a typical Android phone—not a flagship, but the kind of device most people actually use.

CPU throttling is where things get ugly. JavaScript that runs in 200ms on a fast laptop takes 800ms on a throttled mobile simulation—and often longer on real-world budget devices.

Every render-blocking script, every third-party SDK, every unoptimised image decode hits harder on mobile because there’s less CPU to absorb the cost.

Across the stores I’ve audited, desktop Total Blocking Time is typically 100–300ms. On mobile, the same stores hit 800–2,500ms.

That means the page loads visually, but nothing works—the user taps “Add to Cart,” and nothing happens for 2 seconds. Some tap it again. Some leave.

The Revenue Cost of Each Second

Salesforce’s Commerce Cloud data from 1.2 billion mobile shopping sessions found that stores with a Largest Contentful Paint (LCP)—the time to load the main content—under 2 seconds converted at 4.7%, compared to 2.1% for stores above 4 seconds. That’s a 2.2x difference in conversion rate, caused by page speed alone.

A Deloitte study covering 2,400 retail mobile sites found that sites loading in more than 3 seconds had a mobile e-commerce bounce rate of 71.8%.

Each additional second of mobile delay cuts conversions by roughly 20%.

You don’t need more ad spend. You don’t need a redesign. You need the site to load faster on the devices people actually use.

Why Mobile Is Specifically Slow on Shopify

Shopify gives you a solid baseline—global CDN, automatic image compression, HTTP/2. But three things consistently drag down mobile performance, and they all hit mobile harder than desktop because of CPU and network constraints.

Third-Party Scripts Compound on Mobile

I covered this in detail in my audit of 100 stores, but it’s worth restating in the mobile context.

The stores I audited averaged 12–18 third-party scripts: Klaviyo, Gorgias, GTM, Hotjar, review widgets, and upsell pop-ups.

On desktop, those scripts add maybe 400–600ms of Total Blocking Time.

On a throttled mobile CPU, the same scripts add 1,500–3,000ms. The JavaScript doesn’t change—it’s the same code—but the phone has a quarter of the processing power to execute it.

The fix is the same as I outlined before—defer non-critical scripts until user interaction or a timeout.

But the urgency is different when you realise the mobile penalty is 3–5x the desktop penalty for the same scripts.

Unoptimised Images Hit Mobile Twice

A 400 KiB hero image on desktop loads quickly and decodes in milliseconds. On throttled 4G with a budget phone’s CPU, both transfer and decode take noticeably longer.

But the real problem is simpler: many stores serve the same image size regardless of screen width.

A 2000px-wide hero on a 390px-wide phone is downloading roughly 5x the number of pixels needed. Shopify’s image_tag supports responsive images natively—you just have to use them:

{{ product.featured_image 
  | image_url: width: 800 
  | image_tag: 
      srcset: "400,600,800,1200", 
      sizes: "(max-width: 768px) 100vw, 50vw", 
      fetchpriority: "high", 
      loading: "eager" 
}}

A phone on a 1x display gets the 400px version. A retina phone gets 800px. Nobody downloads the 2000px original unless they need it. Across the stores I tested, fixing image sizing alone often cut 200–500 KiB from mobile page weight, which, on throttled connections, translated to 1–3 seconds of faster load time.

The “Looks Loaded, Feels Broken” Problem

The page renders. The hero appears. The user taps “Add to Cart”—and nothing happens.

Then, three seconds later, two items appear in the cart. This is high Total Blocking Time and poor INP in action. The page looks ready, but the main thread is still executing JavaScript.

Google replaced FID with INP as a Core Web Vital specifically because this pattern was so common.

The December 2025 core update raised the stakes—sites with poor Core Web Vitals experienced 20–30% larger traffic losses than faster competitors. CWV shifted from a tiebreaker to a quality threshold.

If you want to go deeper on fixing INP specifically, I’ve written more about optimising for the new INP web vital here.

Fix Mobile First

If you’re limited on time or budget, fix mobile before anything else.

It’s where the majority of your traffic is, where the biggest problems are, and where the revenue impact per improvement is highest.

  1. Test on mobile, not desktop. Use PageSpeed Insights and look at mobile field data. That’s what your customers experience—and what Google ranks you on.
  2. Prioritise your LCP image. Set fetchpriority="high" and loading="eager". Serve responsive sizes. Usually, a 10-minute fix that moves LCP by 0.5–2 seconds.
  3. Defer third-party scripts. Klaviyo, chat widgets, and review apps don’t need to load before the page is interactive. Defer to user interaction or a 5-second timeout.
  4. Break up long tasks. If your TBT is over 500ms on mobile, find the biggest blocking scripts in the Performance tab and defer, split, or replace them.

The gap between mobile and desktop performance is the biggest, most fixable source of lost revenue in e-commerce right now. Your desktop score isn’t the one that matters. Your mobile score is. And it’s almost certainly worse than you think.

Ready to improve your mobile speed and close the revenue gap? Message me or book a call now to get started.