Mobile Performance: Speeding Up Shops on Phones
A shop that loads in under a second on the developer's laptop can still feel sluggish on a customer's phone. The cause is not bad code but two worlds that rarely coincide: a powerful desktop on fiber on one side, a mid-range phone on a cellular network on the other. That gap shows up in the numbers: according to the Web Almanac, only 48 percent (Web Almanac, 2025) of origins pass all three Core Web Vitals on mobile, compared with 56 percent (Web Almanac, 2025) on desktop. This matters all the more because around 57 percent (Statista, 2024) of worldwide e-commerce revenue happens on mobile devices. And patience is thin: 53 percent (Google, 2018) of mobile visits are abandoned when loading takes longer than three seconds. This article shows why mobile performance follows its own rules -- throttled CPU, slower network, small viewport, touch input -- and which levers improve your mobile Core Web Vitals most effectively.
Key takeaways
- What is fast on desktop is not automatically fast on mobile -- a weaker CPU, higher network latency, a small viewport and touch shift all three Core Web Vitals.
- LCP is the hardest vital on mobile, because the largest visible element is usually an image that travels over a slower network.
- Responsively served images with srcset and sizes plus fetchpriority for the LCP image are the most effective levers against long load times on the phone.
- INP suffers on mobile from long JavaScript that blocks the weaker main thread -- generous tap targets belong to it just as much as lean code.
- Mobile is the main channel, not the special case: measuring every change under throttled conditions and reading mobile field data separately wins back conversion.
Why Mobile Performance Follows Its Own Rules
The most common fallacy in performance work is that whatever is fast on desktop is fast on mobile too. In reality, several bottlenecks hit the phone at once that the desktop does not face. A mid-range phone has a markedly weaker CPU, often runs on a cellular network with higher base latency, and renders content on a small screen operated with fingers. Each of these factors shifts exactly the metrics by which Google measures the user experience.
The result is a measurable gap between device classes. It is especially clear for responsiveness: while on desktop 97 percent (Web Almanac, 2024) of pages achieve a good INP score, the mobile share drops noticeably. This discrepancy is not caused by different users but by different hardware -- the same JavaScript load blocks a weak mobile processor far longer than a desktop core. A sound performance analysis therefore consistently separates mobile and desktop field data instead of looking at one averaged figure.
The Three Core Web Vitals -- Briefly Explained
Throttled CPU and Slow Network: How Mobile Is Measured
Anyone serious about testing mobile performance must not use their own high-end machine as the yardstick. The mobile audit in Lighthouse deliberately simulates a realistic device: by default the CPU is slowed by a factor of 4x (Google Lighthouse) to emulate a mid-range processor. On top of that comes network throttling to the Slow 4G profile, which according to the Lighthouse documentation represents roughly the bottom 25 percent (Google Lighthouse) of 4G connections. Only under these conditions do bottlenecks become visible that stay completely hidden on fast hardware.
This throttling is not artificial punishment but an approximation of many users' reality. In numerous markets, 4G still dominates, and not everyone owns the latest flagship. The distinction between two data sources matters: synthetic lab tests like Lighthouse create reproducible conditions, while field data from real sessions (CrUX) reflects the actual variety of devices and networks. In our experience (project experience), only the combination of both sources reveals the true mobile weak spots -- the lab test finds regressions, the field shows the real distribution.
Weaker CPU
A mid-range phone processes JavaScript many times slower than a desktop. Lighthouse emulates this with a 4x CPU slowdown -- long scripts block the main thread there noticeably longer.
Higher Network Latency
Cellular connections have higher base latency and fluctuate heavily. Every additional round trip for DNS, connection or resources costs more time on mobile than on a fixed line.
Small Viewport
On a narrow screen the visible area is small. Which content sits above the fold and which image size is really needed differs fundamentally from the wide desktop layout.
LCP on the Phone: the Most Common Bottleneck
Among the three vitals, Largest Contentful Paint is the hardest on mobile. Only 62 percent (Web Almanac, 2025) of mobile pages pass the LCP threshold, while INP at 77 percent (Web Almanac, 2025) and CLS at 81 percent (Web Almanac, 2025) fare considerably better. LCP is thus the primary bottleneck -- and on mobile it depends heavily on images, because the largest visible element is very often a photo or a hero graphic.
Here lies a classic mobile mistake: the phone is served the same large image file as the desktop. An image displayed 1,200 pixels wide in the broad layout may only need 400 pixels on a narrow phone -- serving the large file anyway sends unnecessary bytes over the slower mobile network. According to web.dev, the sizes attribute tells the browser the expected display width so it can pick the smallest possible file before layout is calculated. Combined with srcset, a single piece of markup serves every screen size appropriately.
<!-- Mobile gets a small file, desktop a large one -->
<img
src="product-800.webp"
srcset="product-400.webp 400w,
product-800.webp 800w,
product-1200.webp 1200w"
sizes="(max-width: 600px) 90vw, 600px"
width="1200" height="800"
fetchpriority="high" alt="Product view">Two details at this markup level have a strong effect. First, fetchpriority="high" accelerates the LCP image by having the browser request it early instead of queuing it behind other resources. Second, fixed width and height values prevent the image from reserving space late and shifting content -- protecting CLS directly. Converting images to modern formats saves weight again; how to do that is explored in our article on image optimization with WebP and AVIF, which is disproportionately effective on mobile.
The Viewport Meta Tag Is Mandatory
INP and Touch: When the Tap Stalls
Interaction to Next Paint measures how quickly the page visibly responds to an input -- on mobile that is usually a touch gesture. This is exactly where the weaker CPU hits hardest. If a long JavaScript runs when a button is tapped, it blocks the main thread and the page responds only with a delay. On desktop a fast core processes the same script in a fraction of the time; on mobile it drags. That explains why desktop reaches a good INP score on 97 percent (Web Almanac, 2024) of pages while the phone stays clearly below.
This is aggravated by the sheer amount of JavaScript shipped to mobile. The Web Almanac measures a median JavaScript payload of around 615 KB (Web Almanac, 2025) on mobile devices -- and rising, with much of it coming from third-party scripts such as analytics, testing, chat and tag-manager tools. Each of these scripts competes for the same main thread, which is already scarce on mobile. How to deliberately reduce such external scripts is covered in our article on trimming third-party scripts.
- Break up long tasks so the main thread regularly frees up for input
- Defer non-urgent work until the interaction is visibly acknowledged
- Make touch targets at least about 44 by 44 CSS pixels with enough spacing
- Keep event handlers lean and move expensive calculations out of the critical path
- Load third-party scripts deferred or conditionally instead of blocking in the head
- Watch mobile INP field data on every release, not just lab scores
An often overlooked aspect is the design of the tap targets themselves. If buttons sit too close together or are too small, the finger misses the target and the user taps repeatedly -- which feels like a slow page even though it is a layout problem. Generous tap-area design therefore belongs to mobile performance just as much as lean code. How to relieve JavaScript specifically is explored in our article on optimizing INP.
CLS: Layout Stability on the Small Screen
Cumulative Layout Shift describes how much content still moves while loading. On mobile this problem is especially annoying: on the narrow screen the content visibly jumps when a late-loading image, an ad block or a late font pushes the text down -- and the user taps the wrong element at the wrong moment. At 81 percent (Web Almanac, 2025) of passing pages, CLS is the strongest of the three vitals on mobile, yet the remaining cases are often frustrating mis-taps.
The remedies are concrete. Give images and media containers fixed dimensions or an aspect-ratio so the browser reserves the space from the start. Load fonts so that no abrupt swap shifts the lines -- how to do that is shown in our article on web font performance. And avoid placing dynamically inserted elements like banners above already visible content; reserve space instead. On the small viewport, every such shift weighs more heavily than on the wide desktop.
| Factor | Desktop | Mobile | Mobile consequence |
|---|---|---|---|
| CPU power | strong | throttled (Lighthouse 4x) | JavaScript blocks longer, INP suffers |
| Network | mostly fixed line | cellular, higher latency | every round trip costs more time |
| Viewport | wide | narrow | smaller images needed, different fold |
| Input | mouse, precise | touch, less precise | large tap targets and spacing needed |
| LCP pass rate | higher | 62 percent (Web Almanac) | images are the main bottleneck |
Measure Mobile-First Instead of Patching Mobile Later
The most effective approach is to make mobile the yardstick from the start instead of patching for the phone at the end. That means checking every change under throttled conditions and reading field data separately by device type. Since the mobile share of revenue dominates at around 57 percent (Statista, 2024), the mobile experience is not a special case but the norm -- and should be prioritized accordingly.
In practice we combine synthetic Lighthouse runs with real user monitoring to bring lab and field together. The lab test with 4x CPU and Slow 4G profile exposes regressions reproducibly before they go live; the field data shows how a change distributes across the real variety of devices and networks. This dual view is part of our performance services, which deliberately consider mobile and desktop separately.
Mobile performance rarely fails because of the code itself, but because of the assumption that one's own fast machine is the yardstick. Whoever checks every change under a throttled CPU and on a slow network sees the bottlenecks before customers feel them.
Mobile performance is also not an isolated topic but closely tied to the server and data side. A slow database query delays the first response on mobile just as on desktop -- only the delay weighs more heavily on the phone. How to improve server-side response time is shown in our article on database query optimization for shop performance. And which resources the browser should request in advance so the critical mobile image loads early is explored in our article on resource hints with preload and prefetch.
The Core in One Sentence
The effort pays off twice. Better mobile Core Web Vitals strengthen organic visibility because Google evaluates the mobile experience, and they simultaneously lower the bounce rate where revenue actually originates. Since 53 percent (Google, 2018) of mobile visits are abandoned beyond three seconds of load time, every hundredth of a second saved on the phone is directly business-relevant -- the lever that a specialized Core Web Vitals optimization serves consistently for the main mobile channel.