Let me start with an image, which suits the subject. Picture yourself packing for a three-day trip and putting in a winter coat, two pairs of boots and a blanket. Will you need them? Probably not. Will you carry them? Absolutely. That is exactly what most pages do with their images: they carry weight the visitor will never see, and then we wonder why they open slowly on a phone.
So let us look at how much that weight actually is, at the two or three mistakes that make it worse, and at what you get when you sit down and fix it. With measurements, not adjectives.
What they really weigh
The HTTP Archive Web Almanac crawls millions of pages and publishes what it finds. In the 2025 edition, the median home page weighs around 2.56 MB on mobile and 2.86 MB on desktop. Of that, images account for roughly 911 KB on mobile and 1,058 KB on desktop.
Do the division: we are talking about a third to a half of the page, in images. And we are talking about the median page, meaning half of them are worse.
There is another finding I consider among the most useful: on inner pages the figures collapse, to 354 KB on mobile and 442 KB on desktop. The weight concentrates on the home page, precisely where first impressions are decided. You worked it out already: that is where to start.
The formats, and a truth that may surprise you
Everybody talks about WebP and AVIF. Let us see how many actually use them. From the 2024 measurement, on mobile:
| Format | Share |
|---|---|
| JPEG | 32.4% |
| PNG | 28.4% |
| GIF | 16.8% |
| WebP | 12% |
| SVG | 6.4% |
| AVIF | 1.0% |
AVIF is on 1%. One per cent, after years of discussion. And GIF, a technology from 1987, is still nearly seventeen times more widespread.
Before you rush to change everything, a correction that needs stating. A number circulates widely, that AVIF saves “60% versus JPEG”, attributed to Google. That is not a Google statement. What the Chrome team actually writes on web.dev is more restrained: that tests have shown savings of more than 50% compared with JPEG in some cases. The “in some cases” is not decoration.
The practical advice stays simple: WebP for everything, AVIF where you have time to test it, always with a fallback. JPEG is not dead, it just fell from 40% in 2022 to 32% in 2024.
The mistake that costs more than any compression
And now the most important part of this article, which even very good developers make.
loading="lazy" is excellent: it tells the browser not to download an image until the user gets close to it. According to the same Web Almanac it is now used on a third of all websites. Good news.
The bad news is the next number: 9.5% of the images responsible for LCP have native lazy loading. One in ten. Which is to say, the single most important image on the page, the one that determines when a visitor considers it “loaded”, has been explicitly declared not urgent.
It is like sending the waiter out with the toothpicks first and the food afterwards. And it gets worse: the page may score better in some tools, because it downloaded fewer bytes overall, while the actual human waits longer.
web.dev states it outright: do not lazy-load images that are likely to be in the viewport when the page loads, especially LCP images. And it adds: use loading=lazy only for images outside the initial viewport.
If you keep one thing from this article, keep that one.
The reverse: tell the browser what is urgent
loading="lazy" says “take your time”. There is an opposite, and fewer people know it: fetchpriority="high".
Without it, images start at low priority and are promoted only once the browser works out that they are visible. With it, they start high immediately. The Chrome team puts it simply, that this causes LCP to happen sooner, and gives an example from Google Flights: LCP from 2.6 to 1.9 seconds, from one declaration.
So the rule is two lines. The main image gets fetchpriority="high" and never gets loading="lazy". Every other image gets loading="lazy" and nothing else.
The two missing numbers that make the page jump
You know the moment when you are reading something on your phone, an image loads above, and the text leaps downwards? You know it. You have sworn at it.
The cause is almost always the same: the image is missing width and height. MDN explains it clearly: with those two, the browser calculates the aspect ratio before the image downloads and reserves the space, reducing or even preventing the shift.
The same MDN adds something few people think about: they are even more important on lazy-loaded images, because an image that has not loaded has a width and height of zero. So the better you do one, the more indispensable the other becomes.
srcset, sizes, and the mistake half of us make
Responsive images exist so you do not send a 2000 pixel photograph to a 400 pixel screen. srcset declares which versions exist, and sizes declares how much space the image occupies in your layout, so the browser can choose.
They are used less than you would think: srcset on 42% of pages on mobile, <picture> on just 9.3%.
And here is the interesting part. The most common mistake is not omitting sizes, it is getting it wrong. The 2024 measurement found the median sizes value to be 16% too large on mobile and 43% too large on desktop. We tell the browser the slot is bigger than it is, it obeys and downloads a bigger file, and so we build an entire saving mechanism and then cancel it with one wrong number.
<picture> is a different story and not for the same job: it is for when you want a different crop per screen, not simply another resolution of the same one.
Our own numbers, since we have covered everyone else’s
All of the above is other people’s measurement. Let me add ours, from projects we ran and measured with MS-Tools.
On osyllektis.gr, a WordPress shop, load time fell from 19 seconds to 4.4. On mswriter.eu LCP went from 10.4 seconds to 2.9. On yachtsgreece.com, where sheer file volume was also the problem, we came down from 35 GB to 7.
Not all of that is down to images, and it would be dishonest to claim otherwise. But a large part of it is, because when images are a third of the weight, there is no serious speed improvement that goes around them.
What I will not tell you
You would expect a number here along the lines of “every second costs you this percentage of sales”. I will not write it, because when I went to verify it I found no independent study behind it.
What does exist is case studies published by web.dev itself, and they are self-reported: Vodafone Italy reports that a 31% improvement in LCP came with 8% more sales. That is real evidence, from an A/B test, but from one company on one page. It is not a rule and I am not promising it to you.
What is certain is humbler and more useful: the page appears sooner, it does not jump, and the phone does not burn data. Whether that brings sales, we measure on your case rather than borrowing it from someone else’s chart.
And a shortcut, for anyone who would rather not
If all this sounded like a lot, there is the automation route. web.dev itself writes that moving to an image CDN can yield 40% to 80% savings in image file size, and that in most cases it optimises them better than a build-time script.
It is not a panacea and it has a cost. But it is an honest option for anyone with a thousand product photographs who is never going to go through them one by one.
Which brings us back to the suitcase. You do not need to travel without clothes, you need to stop carrying the winter coat in August. If you want to see what your site is carrying today and how much of it can go, with a measurement before and after, get in touch.