Performance

Shopify Mobile Speed Optimization

Mobile is the majority of Shopify traffic, and Core Web Vitals are assessed mobile-first — so the mobile number is the number. We test on a mid-range Android over a throttled connection, because that is what your customers are holding, and fix what that device struggles with.

Book a Free Technical Call
Shopify mobile speed optimisation — mobile Core Web Vitals tested on a mid-range Android over a throttled network

Why it matters

Your store is not fast. It is fast on your phone, on your office wifi.

Almost every merchant who tells us their site feels quick has tested it on a recent iPhone, on a strong connection, with the page already cached. Google does not assess it that way. Core Web Vitals are judged on field data from real visits — a 28-day rolling window in CrUX — and the mobile assessment is the one that governs how your store is treated in search. Mobile hardware is where the gap opens up: a mid-range Android has a fraction of the CPU your laptop does, and every kilobyte of app JavaScript costs it several times what it costs you. That is why the mobile score is worse than you expect, and why fixing it needs a different set of decisions than desktop.

Sound familiar?

Search Console says mobile is poor, and nobody on the team can reproduce it.

That gap is almost always a testing problem. The site really is fine on the devices your team uses — and those devices are not representative of your customers.

  • Your only speed testing happens on a recent iPhone, on office wifi, on a warm cache.
  • Search Console flags mobile URLs as poor while your desktop assessment passes comfortably.
  • Mobile converts far worse than desktop and nobody has ruled out speed as the cause.
  • You assume a good Lighthouse score means real mobile visitors are having a good experience.
  • Tapping a variant, filter or cart control does nothing for a second, then everything happens at once.
  • Paid mobile traffic bounces before the hero image has finished painting on a 4G connection.

What's included

What mobile speed work covers

Measured on the hardware and network your customers actually use, then fixed in the theme where the cost originates.

Real devices, not emulation

We test on a mid-range Android handset alongside throttled DevTools profiles, because emulation on a fast laptop flatters the result. The device that matters is the one a customer bought two or three years ago, not the flagship in the developer's pocket. Everything we recommend is validated against that baseline first.

Throttled-network testing

Office wifi hides an enormous amount. We test on constrained connections and cold caches, which is how most mobile sessions genuinely begin — a customer tapping an ad on mobile data with nothing cached. Numbers taken any other way tell you how the site behaves for staff, not for buyers.

Main-thread and JavaScript cost

INP replaced FID in March 2024 and measures responsiveness across the whole session, so main-thread blocking dominates it. On mobile CPUs, the parse and execute cost of app scripts is several times what it is on desktop. We profile long tasks, identify which scripts own them, and defer, replace or remove accordingly.

Mobile layout stability

Small screens make layout shift far more expensive: a banner or badge that nudges content on desktop can move the add-to-cart button under a thumb that is already descending. We reserve space for late-arriving elements — images, sticky bars, cookie notices, app widgets — and hold CLS against the 0.1 threshold on mobile specifically.

Tap targets and mobile usability

Undersized buttons, controls crowded against each other, and inputs that trigger a zoom on focus all read as slowness to a customer even when the metrics look fine. We check the interactive elements on the paths that matter — variant pickers, quantity controls, filters, cart actions — and give them enough room to be hit first time.

Mobile-specific LCP work

The LCP element is often different on mobile than on desktop, because the theme swaps the hero, changes the crop, or stacks the layout. We identify it per breakpoint and make sure the mobile hero is discoverable early, correctly sized for the viewport, and never lazy loaded, which is where LCP under 2.5 seconds is won or lost.

How it runs

How mobile speed work runs.

Two to four weeks of work depending on how much third-party JavaScript is involved. Because Core Web Vitals are graded on a 28-day rolling window of field data, the reported mobile assessment moves about a month after the fixes ship — the lab numbers improve immediately, the public score catches up later.

  1. 01

    Baseline on real hardware

    Field data from CrUX for mobile specifically, then lab traces on a mid-range Android over a throttled connection. You see the difference between that and the office-wifi number before we propose anything.

  2. 02

    Attribute the main thread

    Long tasks profiled and traced back to the scripts that own them, so the conversation becomes which app costs what. Apps you no longer use are the easiest wins and we look for them first.

  3. 03

    Fix the mobile path

    Mobile LCP element prioritised, non-critical JavaScript deferred, space reserved for late elements, tap targets corrected. Every change is verified on the test handset, not on a desktop profile.

  4. 04

    Re-measure and hand over

    Lab re-tests confirm the work, then we track field data over the following month. You get the device profile and the testing method so your team stops measuring on the wrong hardware.

< 2.5s

Mobile LCP

Google's good threshold

200ms

INP ceiling

Responsiveness, whole session

28 days

CrUX window

Rolling field data

Android

Test device

Mid-range, throttled network

Straight answer

Mobile speed work is worth it when mobile is where your money is.

A good fit if…

  • Mobile is the bulk of your sessions and your mobile Core Web Vitals assessment is failing.
  • You run paid social or search traffic that lands on mobile with a cold cache every time.
  • Your store carries several third-party apps and nobody has profiled what they cost the main thread.
  • Mobile conversion trails desktop by a margin you cannot explain through design or merchandising alone.

Probably not, if…

  • Your mobile field data already passes all three thresholds — the gains left are marginal.
  • You want a Lighthouse 100 to show a stakeholder; that is a lab score, not a customer outcome.
  • Your traffic is overwhelmingly desktop B2B, where the mobile assessment barely affects you.
  • You are unwilling to remove or replace any app, because app JavaScript is usually the real cost.

Frequently asked questions

  • Because the hardware is not comparable. A mid-range Android phone has a fraction of the CPU power of the machine you test on, so every script has to be parsed, compiled and executed with far less headroom — and mobile sessions typically start on a slower, less reliable connection with an empty cache. Desktop hides all of that. Google knows this, which is why the assessment is mobile-first. The desktop number is not wrong, it is just measuring an easier problem than the one your customers have.

Mobile failing while desktop passes?

Book a 30-minute call. We'll pull your mobile field data live and run your store on a real mid-range Android, so you can see the gap between your testing and your customers.

Book a free call