What Your Images Actually Cost on a Slow Connection

Every guide about image optimization tells you that big images slow your site down. Almost none of them tell you by how much, which makes the advice easy to nod at and ignore. A megabyte sounds small. Storage is cheap and your own connection is fast, so the cost stays abstract.

So we measured it. One photograph, saved at five file sizes, loaded over three throttled connections with the cache disabled and nothing else competing for bandwidth. The numbers turn out to be much less forgiving than the advice implies.

What we measured

The same source photograph was encoded to five sizes, from 47.5 KB up to 1.87 MB, by varying dimensions and quality. Each was then loaded on its own, in a fresh browser context, with the network throttled through the Chrome DevTools Protocol at three profiles:

• Slow 3G: 400 kbps down, 400 ms latency
• Fast 3G: 1.6 Mbps down, 150 ms latency
• 4G: 9 Mbps down, 85 ms latency

These are deliberately generous conditions. A single image, no stylesheets, no fonts, no scripts, no advertising, nothing else asking for the pipe. Real pages are worse than this.

The relationship is linear, and that is the whole point

Look down any column and the pattern is plain: double the file, double the wait. On a constrained connection, transfer time is bandwidth-bound, and latency is a small fixed cost on top rather than the dominant term.

This is good news, because it means the arithmetic is yours to control. There is no threshold below which size stops mattering and no clever trick that changes the shape of the curve. Every kilobyte you remove comes off the wait in direct proportion.

It also means the worst case is genuinely bad. A 1.87 MB photograph, which is an ordinary unedited export from a phone, takes 38.9 seconds on a slow connection. Not a slow page. One image, alone, on an otherwise empty page. Nobody waits 39 seconds.

The number Google actually scores

Raw transfer time is useful for intuition, but the metric that gets measured in the wild is Largest Contentful Paint: how long until the biggest visible element has rendered. On most article pages, that element is the hero image.

So we built a simple article page, put the hero at three of our sizes, and recorded LCP at a phone viewport.

Google rates LCP as good at 2.5 seconds or under. The interesting row is the middle one. A 498 KB hero already fails that threshold on a Fast 3G connection, at 2.81 seconds. Half a megabyte is not the kind of number that sets off alarms. Most people would call it reasonable. It is the size at which an ordinary article page stops passing on an ordinary mobile connection.

The 1.87 MB hero manages 1.96s on 4G, which technically passes, and 9.80s on Fast 3G, which is a page nobody sees the top of.

Who is actually on a connection like this

It is tempting to treat slow connections as somebody else's problem, in another market, on older hardware. That is not what the data on real users looks like, and it is not what your own week looks like either.

Fast 3G speeds are what you get on a train, in a basement bar, in a lift lobby, in a stadium or conference hall where thousands of phones share a cell, on a rural road, in a hotel with oversubscribed wifi, on a plan that has been throttled after hitting its data cap, or simply while the phone is holding a weak signal indoors. A 4G contract does not deliver 4G speeds all the time; it delivers them when conditions are good.

The other reason this matters more than it appears: the people most likely to be on a degraded connection are also the least likely to wait, because the experience has taught them that waiting rarely pays off. You do not see them in your analytics as frustrated users. You see them as a bounce, or you do not see them at all.

A real page is not one image

Everything above measures a single image in isolation. Put five of them on a page and they queue for the same bandwidth, alongside the HTML, the CSS, the fonts, any third-party scripts and any advertising.

The practical way to think about it is a budget rather than a per-image rule. Decide what the whole page may weigh, then divide. A useful starting point for an article page is to keep total images under about 500 KB, with the hero taking no more than half of that. That is not a standard anyone enforces; it is roughly the point at which our measurements stop producing embarrassing numbers on a mid-range connection.

Per role, that works out at something like:

How to actually hit those numbers

The order of operations matters, because each step makes the next one cheaper.

Right-size first. This is the largest single lever and the most commonly skipped. An image displayed 800 pixels wide gains nothing from being 3000 pixels wide, and the extra pixels cost real seconds. Use the image resizer to bring it down to the size it is actually displayed at, doubled if it needs to stay sharp on high-density screens.

Then change format. WEBP was the smallest widely supported format in every test we have run, typically around 40 percent below JPG at equivalent quality. The image converter handles it, and our format comparison has the measured sizes if you want to see the gap.

Compress last, to a target. Rather than guessing at a quality slider, set the size you want. The image compressor takes a target such as 150 KB and searches for the highest quality that fits underneath it, which turns a vague intention into a number you can rely on.

All three steps can run on one upload rather than three separate rounds of download and re-upload, which we covered in doing the whole job in one pass. On a previous test that chain took a 3.26 MB export down to 61.7 KB with no visible difference at display size. Against the table above, that is the difference between a 39 second wait and a 1.4 second one.

What helps less than you would hope

Lazy loading does not rescue your hero. It is genuinely valuable for images below the fold, and you should use it there. But the LCP image is by definition visible immediately, so deferring it either does nothing or makes things worse. Never lazy-load the hero.

A CDN reduces latency, not payload. Moving the file closer shaves the fixed cost, which our measurements show is the smaller term on a slow link. A 1.87 MB image served from a nearby edge is still 1.87 MB going through a 400 kbps pipe.

Faster networks are not arriving to save you. Average speeds rise, and so do average page weights, which is why the typical page has not got noticeably faster in a decade. The connection your visitor has at the moment they tap the link is the only one that counts.

Compressing an already-small image is diminishing returns. Going from 47.5 KB to 40 KB buys you two tenths of a second on Slow 3G. Going from 1.87 MB to 150 KB buys you thirty-six. Spend your effort at the top of the range.

The short version

Transfer time scales directly with file size, so every kilobyte has a price measured in seconds. A half-megabyte hero, which most people would consider unremarkable, already misses Google's LCP threshold on a mid-range mobile connection. Right-size before you compress, use a modern format, and set an explicit target rather than eyeballing a quality slider. And if you want to know what your own pages cost, throttle your browser to Fast 3G and load one. It is a short and clarifying experience.