Website Speed on Mobile Data: What Your Page Weight Costs
Your site loads fine when you test it from the office. Then a customer opens it on the bus, on mobile data, and it sits on a blank screen. Nothing changed on the server. What changed is the pipe, and website speed on mobile data is decided long before your server is even involved, because page weight is what travels down the customer’s pipe.
This article puts a number on that cost. We fetched the homepages of three sites we shipped, wrote down every byte on the wire today, and translated the weights into seconds on a throttled phone connection. One of our own assets turned out to be the heaviest thing we own. We also show what we cut first when a page is too heavy.
What a phone connection actually is
When we profile a site for speed, we do not use our office wifi. We use the same preset Chrome DevTools uses when you pick “Slow 4G” in the Network tab: 1.6 megabits per second download and a 150 millisecond round trip. Those are not random numbers. They are the same ones Lighthouse runs for its default mobile audit, documented in Lighthouse’s throttling reference, and the Chrome DevTools team documents the same presets in their throttling settings.
Two things follow from that preset. First, 1.6 megabits is 200 kilobytes per second. Not 200 kilobytes of goodput in the best case: 200 KB/s is the ceiling before overhead, packet loss, and signal drops push it lower. Second, every round trip costs 150 milliseconds. The DNS lookup, the TLS handshake, and the first request all pay it, and they stack into whole seconds before a single byte of your page has moved.
A strong LTE connection on a good day beats this preset. A phone with two bars in a concrete building does not. If your page is fast enough at 1.6 Mbps, it is fast enough almost anywhere in Pakistan, and if it is not, you now know exactly which ceiling your visitors hit.
The median page is 2.3 megabytes
HTTP Archive crawls over a million pages every month and publishes the results as the Web Almanac. In their 2024 page weight chapter, using data collected in October 2024, the median mobile page weighed 2,311 KB. The median mobile homepage carried 900 KB of images and 558 KB of JavaScript, so about 63 percent of everything downloaded was either an image or code. A year later the same chapter reports the median mobile homepage at 2.6 MB, up 8.4 percent. Pages are getting heavier, not lighter.
HTML is tiny: 18 KB on the median mobile homepage. The stuff that makes a page look finished is what eats the connection.
Here is what we measured today on three sites we built and shipped, wire bytes straight off the server:
| Site | HTML on the wire | What it is |
|---|---|---|
| mtufaildiagnosticcenter.com | 10 KB | diagnostic centre, Kasur |
| warasat.com.pk | 63 KB | real-estate agency, Sialkot |
| truckaxic.com | 116 KB | US truck dispatch |
| median mobile page | 2,311 KB | HTTP Archive, Oct 2024 |
The gap between the third row and the fourth is not luck. It is a set of decisions about what deserves to be downloaded, which is the same set of decisions this article walks through.
The arithmetic of website speed on mobile data
The math from weight to time is simple division, and it is worth doing once for your own site. Take your page weight in kilobytes and divide by 200. That is pure transfer time on Slow 4G, in seconds, before the browser parses anything.
The median page from the Web Almanac’s 2024 crawl, 2,311 KB, divided by 200 KB/s is about 11.5 seconds of pure transfer, and real-world time lands higher once parsing and staggered requests are added. That is a visitor staring at whatever the browser has managed to paint so far, usually a background and half a headline.
Here is the same arithmetic on our own builds, with one number we are not proud of. The 10 KB homepage of the diagnostic centre site transfers in a rounding error. Its single JavaScript bundle, though, measured 707 KB uncompressed on disk and 219 KB over the wire with gzip. At 200 KB/s that bundle alone costs 1.1 seconds of transfer, more than a hundred times what its HTML costs. It is the heaviest single asset we ship, and we only found it because we weighed each part instead of the page total.
Weight does not just cost seconds. Google and SOASTA measured what happens when load time stretches out: as mobile load time goes from one second to three seconds, the probability of a visitor bouncing increases 32 percent, per Google/SOASTA Research published by Think with Google. The same research shows the bounce probability more than doubling by ten seconds. Every kilobyte is spending someone’s patience, and patience is the resource your enquiry form needs.
The bar to clear
Google publishes the thresholds it treats as a good experience in Web Vitals: the main content of the page should render within 2.5 seconds (Largest Contentful Paint), the page should respond to a tap within 200 milliseconds (INP), and the layout should not shift more than 0.1 (CLS), all measured at the 75th percentile of real visits. The same thresholds are what Google documents for search ranking context. They are the widely accepted bar, and they are achievable on a throttled connection, but not with a 2 MB page in front of them.
Our own target on every build: the whole first view lands under about 300 KB on the wire. Three HTML documents we measured today sit at 10, 63, and 116 KB, which leaves most of that budget for the hero image and the fonts, where the money should go. We do not hit a number for the badge. We hit it because a small first view is the only performance strategy that works when the network is the constraint.
What we cut first
When a page is too heavy on mobile data, we cut in this order. It is the same order whether the site is ours or a client’s.
First, weigh the page. Open DevTools, Network tab, pick Slow 4G, reload, and sort by size. Write down the top five. Most pages have one asset that outweighs everything else, like our 219 KB bundle did.
Second, cut the JavaScript that runs nothing the visitor came for. Carousels, animation libraries, chat widgets that load on every page. The median mobile page ships 558 KB of JavaScript per the Web Almanac, and on a small-business site most of it guards features nobody clicked last month. Removing a library is a deletion, not an optimisation: the bytes go to zero.
Third, right-size the images. Serve modern formats, sized to the slot they fill, with responsive sizes and srcset so a phone does not download a desktop hero. On warasat.com.pk the property photos ship as WebP with four widths; the 800-pixel rendition measures 66 KB.
Fourth, load only what the first view needs. The contact form’s validation script can wait until someone scrolls to the contact form. This is the cheapest lever on the list because it changes positions, not code.
Fifth, set a font budget. Two families, a few weights, loaded with the font display swap property so text renders while the real font arrives. The diagnostic centre site pulls Inter and Poppins from Google Fonts, weights 300 through 800: eleven variants to cover designs we barely use. The swap makes it harmless on first paint, but it is the next thing we would rationalise.
The order matters. Byte cuts compound: fewer scripts means fewer blocking requests, which means the round-trip tax shrinks along with the transfer. Do not start with caching or a CDN while a 2 MB payload is still the payload.
Where this leaves you
Run your own homepage through the Slow 4G throttle once. Note the weight, then note where the Largest Contentful Paint lands against the 2.5-second bar. If it clears, you are ahead of the median page by a factor of seven, and your visitors on mobile data will feel it. If it does not, sort by size and start deleting at the top, using the order above.
We put this checklist in front of every build before launch, and it is part of how we build at Dev2Production: our web development service bakes the weight budget in from the first commit, and the AI agent work we ship answers the same constraint on the backend, where a slow endpoint loses the same customers a slow page does. If you want a second pair of eyes on your own numbers, write to us with the URL and we will send you the asset list.
FAQ
Why is my website slow on mobile data but fast on wifi? Office wifi runs tens of megabits per second with a short round trip. Mobile data with a weak signal can run near the Slow 4G preset: 1.6 Mbps down, 150 ms round trip. The same 2 MB page takes under a second on one and over ten seconds on the other. Nothing is wrong with the server; the page is too heavy for the pipe your visitor has.
What is a good page weight for a small-business website? There is no official budget, but a practical target we hold on our own builds is roughly 300 KB for the first view. That leaves room for a real hero image and two fonts while keeping pure transfer time near 1.5 seconds on a throttled connection. For reference, the median mobile page was 2,311 KB in the Web Almanac’s 2024 data, so staying under a third of that puts you well ahead of most of the web.
Does compression solve slow mobile loading? It helps and it is not enough. Gzip took our 707 KB JavaScript bundle down to 219 KB on the wire, a 69 percent cut that cost one configuration line. But 219 KB still costs over a second of pure transfer on Slow 4G. Compression multiplies whatever you already have; it cannot fix a page that ships features nobody uses. Delete first, compress second.
How do I check my page weight without installing anything? Open the page in Chrome, press F12, click the Network tab, pick “Slow 4G” from the throttling menu, and reload. Chrome shows the total transferred size at the bottom of the panel and lets you sort requests by size. If one asset is over 100 KB on a small-business site, that is usually the first thing to fix.
Will faster hosting fix my mobile speed? Not by much. Hosting moves the first byte earlier, which helps by a few hundred milliseconds. The dominant cost on mobile data is transfer time, which scales with page weight no matter where the server sits. Moving hosts before cutting weight is paying rent on a bigger pipe to deliver the same oversized parcel.