Key takeaways
- Shopify mobile speed is a different problem from desktop. Phones have slower CPUs and sit on variable networks, and mobile is where most storefront traffic and conversions happen.
- Google grades three Core Web Vitals on mobile: LCP, CLS, and INP. It measures them from real-world field data at the 75th percentile, reported separately for mobile.
- The tactics that move the needle are responsive images from Shopify’s CDN, lazy-loading below-the-fold media, deferring non-critical JavaScript, and cutting app scripts.
- App bloat is the biggest mobile speed killer. Every widget app injects its own JavaScript into every page, and that runs on the phone too.
- Fudge writes lean native theme code instead of adding another widget app, so a feature ships without the script tax an app charges on every page load.
Getting Shopify mobile speed right is not the same job as tuning desktop. A page that feels instant on a laptop with fibre can crawl on a mid-range phone on a patchy mobile network. And since most Shopify traffic and most Shopify checkouts happen on phones, mobile is the version that actually decides your revenue.
This guide covers why mobile is harder, which Core Web Vitals Google grades, the concrete tactics that reduce mobile page speed problems, and how to test the way your slowest shoppers experience the store.
Why you can trust us
Jacques has 15+ years of development experience and has worked on storefront performance across hundreds of Shopify stores. We build Fudge, an AI storefront editor with a 5.0 rating on the Shopify App Store, so we work on the same theme layer that mobile speed lives on and we see what a bloated app stack does to a phone.
Why mobile speed is a different problem from desktop
The same theme runs on both, but the conditions do not match.
Phones have slower CPUs. A mid-range Android device parses and executes JavaScript far slower than a desktop. Script-heavy pages that feel fine on a laptop can stall on a phone, because the phone spends longer on the main thread running the same code.
Mobile networks are variable. A shopper might be on fast 5G at home and slow 3G on a train ten minutes later. Every extra request and every oversized image costs more on a slow, high-latency connection.
Mobile is where the money is. For most Shopify stores, mobile is the majority of both sessions and orders. That makes the mobile render path the one worth spending your effort on first.
So the goal is not a good desktop score. It is a page that stays fast on a cheap phone and a slow connection, because that describes a large share of real shoppers.
Core Web Vitals on mobile: the metrics Google grades
Google’s page experience signals are built on Core Web Vitals. There are three, and INP became a stable Core Web Vital in 2024, replacing First Input Delay.1
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading: when the largest element renders | 2.5s or less | over 4s |
| INP (Interaction to Next Paint) | Responsiveness: how fast the page reacts to taps | 200ms or less | over 500ms |
| CLS (Cumulative Layout Shift) | Visual stability: how much the layout jumps | 0.1 or less | over 0.25 |
The thresholds are the same on mobile and desktop, but the numbers you hit are not. On a phone, a large hero image drags LCP up, and heavy scripts drag INP up as the main thread stays busy.
Why the field data is mobile-weighted
Google assesses Core Web Vitals from real-world field data, not from a single lab test. That data comes from the Chrome User Experience Report and is evaluated at the 75th percentile of visits, so a store passes only when three quarters of real sessions clear the threshold.1
That field data is reported separately for mobile and desktop. Combined with mobile-first indexing, where Google predominantly uses the mobile version of a page for indexing and ranking, the practical takeaway is simple: your mobile experience is the one that carries the weight.
For the wider context on where Shopify stores actually stand, see our state of Shopify performance report.
How to improve Shopify mobile speed
The wins are concentrated in a few areas: images, scripts, and layout stability. Here is where to spend the effort.
Serve responsive images from Shopify’s CDN
Images are usually the heaviest thing on a product or collection page, and phones do not need desktop-sized files.
Shopify’s image CDN can resize an image on the fly. The image_url Liquid filter returns a CDN URL at whatever width you ask for, and the CDN automatically serves a modern format like WebP or AVIF when the browser supports it.2
Pair that with srcset and sizes so the browser downloads a file matched to the device. With width descriptors in srcset and a sizes hint, the browser picks the smallest source that still looks sharp, which spares a phone from pulling a 2000px image into a 400px slot.3
The single biggest LCP win on mobile is usually shrinking the hero image. For the full walkthrough, see how to compress images in Shopify.
Lazy-load below-the-fold media
Everything below the fold can wait. The native loading="lazy" attribute on an <img> tells the browser to defer that image until it approaches the viewport, which cuts the number of requests competing at first load.4
Use it for images and iframes further down the page: lifestyle shots, review sections, footer logos, embedded video. Do not lazy-load the LCP element itself, since deferring your hero image will make LCP worse, not better.
For the details, including how to handle embedded video, see how to lazy load images in Shopify.
Defer non-critical JavaScript
JavaScript is what hurts INP most on mobile, because the phone’s slower CPU spends longer executing it and the main thread stays blocked.
Anything not needed for the first paint should not block it. Add defer to scripts so they load without holding up rendering, and load non-essential widgets after the page is interactive rather than in the head.
Render-blocking scripts are worth a dedicated pass. See how to fix render-blocking scripts in Shopify for the specifics.
Cut app scripts
This is the one most stores underestimate. Nearly every widget app injects its own JavaScript into your storefront, and that script runs on the phone on every page. A stack of a dozen apps can add a payload that no amount of image tuning will offset.
Audit what each app actually costs. Remove apps you no longer use, and for features you can build in the theme, prefer native code over another script tag. More on this in the section below.
Add critical CSS and set font-display
Two smaller wins that help first paint:
- Critical CSS. Inline the styles needed to render the top of the page so the browser can paint before it fetches the full stylesheet.
- font-display: swap. Let text render in a fallback font immediately while the web font loads, instead of leaving a blank space. This avoids invisible text on a slow connection.
Stop layout shift from banners and hero sections
CLS is often the easiest vital to fix, because the causes are structural. Layout jumps come from elements that load late and push content down: an announcement bar, a hero image without reserved space, a cookie notice, a late-injected app widget.
Reserve space for anything that loads after first paint. Give images explicit width and height attributes so the browser reserves the slot before the file arrives, and avoid inserting banners above content that has already rendered.
How to test on 3G and slow devices
You cannot judge mobile speed from your own phone on office wifi. You have to simulate the conditions your slowest shoppers face.
Run Lighthouse in mobile mode. In Chrome DevTools, the Lighthouse panel defaults to a simulated mid-tier mobile device with throttled CPU and network. That is a closer proxy for real mobile than a desktop run.
Throttle the network. In the DevTools Network tab, set throttling to a slow profile such as “Slow 3G” and reload. This exposes the requests that hurt on a high-latency connection, which a fast connection hides.
Throttle the CPU. In the Performance tab, apply a 4x or 6x CPU slowdown to emulate a low-end phone. Heavy JavaScript that runs instantly on your machine will show its true cost here, which is what INP is measuring.
Check field data too. Lab tests catch a lot, but Google grades on field data. Watch the Core Web Vitals report in Search Console, which is segmented by mobile and desktop, so you can confirm real visits are passing and not just your lab runs.
Test after every significant change, especially after installing an app. An app that looks harmless in the admin can add real weight to every page.
App bloat is the real mobile speed killer
If you fix one thing, fix this. Images and CSS matter, but the largest and most common drag on Shopify mobile speed is the app stack.
The pattern repeats across stores. Each app that adds a visible feature (a sticky bar, a review widget, an upsell popup, a currency selector) usually ships its own JavaScript, and that script loads on the phone on every relevant page. Individually each one seems small. Stacked together they block the main thread, delay interactivity, and inflate INP.
The heaviest offenders also cause layout shift, because they inject their UI after the page has already rendered, pushing content around and hurting CLS.
The fix is not to accept it as the cost of features. Many of these features are a small amount of theme code. Building them natively, instead of adding another app, means the feature ships with none of the per-page script tax. If your store is already slow, start there before adding anything new: how to speed up a Shopify theme walks through the audit.
Where Fudge fits
The usual way to add a storefront feature is to install an app, and every app you install is more JavaScript on every page, which lands hardest on mobile.
Fudge takes the other path. It is an AI storefront editor that writes native theme code. You describe what you want, and it writes the Liquid, CSS, and JavaScript directly into your theme.
Because the output is native, a feature you build with Fudge does not carry a third-party widget or an extra script loading on every page from an app. That is the difference that shows up in your mobile Core Web Vitals: fewer render-blocking scripts, less main-thread work, and no late-injected widget causing layout shift.
And because it is theme code, it survives uninstall. Whatever you build with the Shopify store editor stays in your theme even if you cancel, unlike an app-rendered element that disappears the moment you remove the app.
FAQ
Phones have slower CPUs and sit on variable, higher-latency networks, so the same theme takes longer to download and execute on a phone. Large images and heavy app scripts that a desktop absorbs easily will stall a mid-range phone. Since Google measures Core Web Vitals separately for mobile, the mobile version is the one that decides both rankings and most of your conversions.
Aim for Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Google grades these from real-world field data at the 75th percentile, so you pass only when about three quarters of real visits clear the threshold.
Usually yes. Most widget apps inject their own JavaScript into every relevant page, and that script runs on the phone, blocking the main thread and delaying interactivity. Late-injected app widgets also cause layout shift. Auditing and removing apps you no longer need, or replacing them with native theme code, is often the single biggest mobile speed win.
Open Chrome DevTools, go to the Network tab, and set throttling to a slow profile such as Slow 3G, then reload. Add a CPU slowdown in the Performance tab to emulate a low-end phone, and run Lighthouse in its mobile mode. Together these approximate the conditions your slowest shoppers face far better than testing on office wifi.
No. Lazy-loading defers an image until it nears the viewport, which is right for below-the-fold media but wrong for the hero. Your hero is usually the Largest Contentful Paint element, so deferring it makes LCP worse. Lazy-load review sections, footer logos, and embedded video instead, and let the hero load eagerly.
Yes. Core Web Vitals are part of Google's page experience signals, and Google uses mobile-first indexing, meaning it predominantly ranks the mobile version of a page. Since the field data is reported separately for mobile, a slow mobile experience can hold back rankings even if the desktop version is fast.
Footnotes
-
web.dev, “Web Vitals” - the three Core Web Vitals are LCP (good at 2.5s or less), INP (good at 200ms or less), and CLS (good at 0.1 or less), assessed from field data at the 75th percentile. INP became a stable Core Web Vital in 2024, replacing First Input Delay. https://web.dev/articles/vitals ↩ ↩2
-
Shopify Dev, “image_url filter” - returns the CDN URL for an image at a specified width or height, and the CDN automatically detects and serves supported formats such as WebP and AVIF for optimal quality and file size. https://shopify.dev/docs/api/liquid/filters/image_url ↩
-
MDN Web Docs, “The Image Embed element (img)” - with width descriptors in
srcsetand asizeshint, the browser selects the most appropriate image source for the device and viewport, balancing quality and performance. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img ↩ -
MDN Web Docs, “The Image Embed element (img)” -
loading="lazy"defers loading of an image until it reaches a calculated distance from the viewport, reducing bandwidth and requests for below-the-fold images. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img ↩