Your Website Images Are 10x Too Big. We Measured Ours.

We audited our own site last week and found 11.3 MB of images sitting where under 1 MB would have done the same job. Six blog cover pictures, averaging 1.9 MB each. Not a client site. Ours.

That is worth writing up, because the mistake is boring, extremely common, and costs nothing to fix. It is also worth being precise about who was actually paying for it, because the honest answer is narrower than most articles on this subject will tell you.

What we found

Every one of those covers was a PNG. PNG is a lossless format: it stores a perfect copy of every pixel. That is exactly right for a logo, a screenshot with sharp text, or anything needing a transparent background. It is the wrong choice for a photograph or a detailed illustration, where it stores roughly ten times the data of a lossy format nobody can tell apart from it.

We re-encoded the same six images to WebP at quality 85 and compared them side by side before trusting the number. The lettering and the logo in each one stayed clean.

• 11.34 MB of PNG became 0.95 MB of WebP, a 91.6% reduction
• The largest single file went from 2.28 MB to 160 KB
• No visible quality loss at the size these render on the page
• Total time: one afternoon, including checking each one by eye

What a visitor actually downloads

Here is the part most write-ups skip, and it changes how much you should care.

Our site runs images through Next.js's image optimizer, which re-encodes on the fly and serves AVIF or WebP to any browser that says it can take one. So the 2.28 MB file was never sent to a normal visitor. They were already getting about 98 KB. Re-encoding the source did not change their experience at all.

The bar that moved is the third one. That is what the server sends to a client which cannot advertise a modern format: some crawlers, some in-app browsers inside apps like Instagram and LinkedIn, and some corporate proxies. Before the change they received a 599 KB PNG. Now they get a 164 KB JPEG.

One detail worth knowing if you go looking: with a WebP source, that fallback comes out as JPEG, not WebP. Next deliberately refuses to hand a WebP file to a client that did not ask for one. So "convert everything to WebP and everyone gets WebP" is not what happens, and believing it is how people end up deleting their originals.

So is it worth doing?

Yes, for three reasons, none of which is the one usually given.

1. The in-app browser share is not small in India. A large slice of traffic to a local business arrives from a WhatsApp, Instagram or Facebook link, opened inside that app rather than in Chrome. That is exactly the population most likely to fall back, and most likely to be on a metered connection.
2. Your origin pays every time the cache is cold. Our optimizer re-fetches the original at every size after each deploy. That transfer went from 11.34 MB to 0.95 MB. If you host images on a service that bills for egress, this is a line on a bill.
3. Nothing else you do to a page is this cheap. There is no redesign, no rewrite, no risk. It is a format change on a handful of files.

What it is not: a fix for a slow site. If your pages are slow, images are one candidate and usually not the biggest. Render-blocking scripts, an overloaded shared host and a bloated page template all beat images regularly. Fix this because it is free, not because you expect the site to feel different afterwards.

How to check your own site in five minutes

1. Open your site in Chrome, press F12, and go to the Network tab. Filter by Img and reload.
2. Sort by size. Anything over about 200 KB on a page that is not a photography portfolio is worth a look.
3. Check the Type column. If you see png on photographs, that is the finding.
4. Now the part people miss: right-click the largest one, copy the URL, and fetch it with a plain request that does not advertise WebP or AVIF support. That tells you what the fallback weighs, which is the number that actually changed for us.

If you are on WordPress, a plugin will convert to WebP and keep the originals. If you are on Shopify, it converts automatically and there is nothing to do. If you have a custom build, the conversion belongs in whatever handles uploads, so it happens once at upload time rather than as a chore someone has to remember.

The rule we now use

Photographs and detailed illustrations go in a lossy format, WebP for preference. Logos, icons, screenshots with small text and anything needing transparency stay PNG, or better, become SVG where they can. Nothing is a PNG by default just because that is what the export dialog opened on.

We also moved the conversion into the upload path on our own backend, so this cannot quietly come back the next time someone adds a cover image. Fixing the six files was the smaller half of the job.

Common questions

Will converting to WebP make my images look worse?

At quality 80 to 85, not in any way a visitor will notice on a screen. We checked each of ours by eye at full size before shipping, specifically looking at the text and the logo inside the picture, because that is where compression artefacts show first. If you are printing the image or your visitors will zoom deeply into fine detail, keep a lossless master and serve the WebP.

Do all browsers support WebP?

Effectively yes. Every current browser has supported it for years. The clients that do not are the fallback population described above, and a properly configured site serves them a JPEG automatically rather than breaking.

Should I use AVIF instead?

For delivery, yes, and most modern setups already do. AVIF is roughly a quarter smaller again than WebP on photographic content. For the file you store and keep, WebP is the more practical master because more tools can open and edit it.

How much will this improve my PageSpeed score?

Honestly, possibly not at all, because PageSpeed tests with a browser that already receives the optimized format. That is not a reason to skip it. It is a reason to be suspicious of anyone who promises a score jump from an image conversion alone.