Mobile Performance on Slow Networks

The gap between mobile and desktop

HTTP Archive's 2025 Web Almanac, which analyzed July 2025 data, found that 48% of mobile websites passed all three Core Web Vitals, compared with 56% on desktop. The gap is widest for Largest Contentful Paint (62% good on mobile, 74% on desktop) and Interaction to Next Paint (77% versus 97%) ^[1]. Interestingly, mobile did better than desktop on Cumulative Layout Shift, at 81% against 72% ^[1]. Phones are not worse at everything; they are worse at loading and responding.

Google reports mobile and desktop separately in Search Console's Core Web Vitals report, so a page can be good on one and poor on the other ^[2]. Google also recommends judging each metric at the 75th percentile of page loads, segmented by device type ^[3].

Why phones struggle

• Slower processors: JavaScript takes longer to parse and run on a mid-range phone than on a laptop, which keeps the main thread busy and slows responses to taps.
• Variable networks: mobile connections vary with location and signal strength, and latency adds up on every request, especially to many third-party domains.
• Smaller screens, same files: if a site sends desktop-sized images to phones, they pay for pixels they never display.
• Less memory: heavy pages can push phones to discard background tabs, which means more full reloads.

Testing like a phone

Testing on your own fast device tells you little about the visitors at the 75th percentile. Chrome DevTools lets you calibrate CPU throttling presets that approximate "the typical performance of low- and mid-tier mobile devices", and define custom network profiles with download and upload speeds and latency ^[4]. A practical routine:

1. Pick three or four key templates and always test the same ones.
2. Turn on CPU throttling and a slower network profile.
3. Record a performance trace and note LCP, layout shifts and long tasks.
4. Try the main interactions: menus, filters, forms and add-to-cart buttons.
5. Repeat each test a few times, since results vary between runs.

Field data remains the final word. PageSpeed Insights shows real-user data for mobile and desktop from the previous 28 days ^[5]. Keep in mind that CrUX does not include Chrome on iOS ^[6], so if many visitors use iPhones, test on Safari too.

What to fix first on mobile

Images

Serve sizes that match phone screens using srcset and sizes; web.dev notes that sending desktop-sized images to phones can use two to four times more data than needed ^[7]. Make sure the main image is in the HTML, prioritized and not lazy-loaded ^[8].

JavaScript

Every script costs more on a phone. Remove unused code, delay non-essential third-party tags until after load, and break long tasks into smaller pieces ^[9]. Google lists avoiding unnecessary JavaScript among its top three INP improvements ^[10].

Server response

Latency hurts more on mobile networks, so a slow first byte leaves even less time for everything else. Page caching and a CDN help here; Google lists using a CDN among its most effective LCP improvements ^[10].

Fonts

Each font file is another download on a slow connection. web.dev recommends WOFF2, subsetting, fewer families and weights, and choosing font-display deliberately ^[11].

Back and forward navigation

Phone users often go back and forth between a list and a detail page. The back/forward cache makes those navigations instant, and web.dev's main advice for keeping pages eligible is never to use the unload event ^[12].

Design choices that help phones

Some speed problems start in the design. Autoplaying video backgrounds, large carousels and pop-ups that appear after load all cost more on phones. Google's page experience questions ask whether pages avoid intrusive interstitials and whether content displays well on mobile ^[13]. Simpler mobile layouts are often both faster and easier to use.

Setting realistic expectations

Some visitors will always be on slow connections or older devices. The goal is not to make every visit instant; it is to make three out of four visits meet the thresholds, and to make the slowest visits usable. A page that shows its main content quickly, responds to the first tap promptly and does not jump around will feel acceptable even on modest hardware.

A worked example: the same page on two phones

Take a fictional restaurant site's menu page. On a recent flagship phone over strong Wi-Fi it appears in about a second and the menu tabs switch instantly. On a three-year-old mid-range phone with weak signal, the hero image takes several seconds, a web font swap makes the text jump, and switching tabs takes half a second because a reservations widget is still starting up. Both visits count. If enough visits look like the second one, the page fails at the 75th percentile even though the owner, testing on their own phone, never sees a problem ^[3].

The fixes are the familiar ones applied with phones in mind: a smaller, prioritized hero image ^[8], fonts with matched fallbacks or font-display: optional so the swap does not shift text ^[11], and the reservations widget loaded when its section is reached rather than on page load.

Data costs and lighter pages

Not every visitor has unlimited data. Heavy pages cost them money and battery as well as time. Lighter pages, with right-sized images, fewer fonts and less JavaScript, are kinder to these visitors and faster for everyone. A useful habit is to check the total transfer size of key pages in your browser's developer tools and set a rough budget for each template, then notice when a change pushes a page over it.

Touch targets, pop-ups and perceived speed

Performance and usability overlap on small screens. A page that technically loads quickly but immediately covers the content with a sign-up pop-up feels slow, and Google's page experience questions specifically ask whether pages avoid intrusive interstitials ^[13]. Small, crowded buttons that cause mis-taps make every interaction feel slower than it is. Giving tap targets enough size and spacing, and keeping overlays small and easy to dismiss, improves how fast a page feels without changing a single metric.

A mobile checklist

• Test key templates with CPU and network throttling, not only on your own phone.
• Serve phone-sized images and prioritize the main one.
• Keep JavaScript lean and delay non-essential third-party tools.
• Reserve space for images, embeds, ads and banners.
• Limit font files and match fallback metrics.
• Check that pages work with the back/forward cache.
• Review field data for mobile separately from desktop.

iPhones and Safari

Because CrUX does not include Chrome on iOS ^[6], and Safari users are not in CrUX either, field data can say little about iPhone visitors. That does not mean they have no problems. Testing key templates in Safari on a real iPhone, or in a simulator, catches issues the Chrome-based tools miss, such as differences in how fonts and images load. If your analytics shows many iPhone visitors, give their experience the same attention as Android visitors, even though Search Console will not report it directly.