guides/What compression really saves
GUIDE

What compression really saves

Every compression tool advertises a percentage, and almost every percentage is an artefact of the files that were fed to it. Here is what a mixed batch actually did, split by source format.

PNG → WEBP−96%12 files, 27.6 MB in
JPG → WEBP−56%4 files, 560 KB in
BLENDED AVERAGE−95%meaningless — see below

Why the average lies

In that batch the JPGs were 1.9% of the bytes. A weighted average over those inputs is therefore almost entirely a measurement of the PNGs, which is why it reads 95%. Quote it and you are promising a result that only holds for one kind of file.

The two honest numbers are the split ones. And the −56% for JPGs has now been measured twice, on different sets, landing in the same place both times.

The PNG figure is a format change, not compression

A 2.5 MB PNG of a photograph collapsing to 96 KB is not a clever encoder. It is a lossless format being replaced by a lossy one at quality 0.75. Any tool does that. The difficulty was never one file — it is doing it to two hundred without freezing the browser.

Already-optimized files get bigger

Re-encoding a file that was already compressed below the quality you are asking for inflates it, and recovers nothing, because the original loss is already baked in. Measured with the same libwebp a browser uses: a file encoded at quality 45 came out 17.7% larger when re-encoded at 0.78.

On a batch of 17 such files, 15 were left untouched and the batch still reported a positive saving. Without that guardrail it would have grown.

Where the time actually goes

Across 300 files and 503 MB, decoding averaged 16 ms per file and encoding 84 ms. Encoding is 84% of the cost, which looks like the case for a WebAssembly encoder — until you notice that the browser's own encoder is already native code. A WASM build of the same library runs slower, not faster.

Measured on the format a browser genuinely cannot encode: AVIF took 9.7 times longer for 10% fewer bytes, and that was native. On a 300-file batch that turns three seconds into a minute.

Memory is not the wall

503 MB of input left the browser tab at 92.9 MB, with 23.9 MB of results held in memory. The limit people expect to hit first is not the one that bites.

PrensoDecodes and re-encodes in this tab. Works offline.