HTTP Compression
Today (in 2024), there are three practical choices for encoding HTTP content.
No compression
content-encoding: identity
This is the best choice for content types that are already compressed, such as:
- Images
(image/png, image/jpeg, image/webp, image/avif) - Videos
(video/*) - Fonts
(font/woff2) - Archives
(application/zip)
This also makes sense for:
- Very small content
(under 1kb)The savings are not worth the overhead. - Localhost only servers
(dev servers or admin servers)Bandwidth and network speed are not a concern.
Gzip compression
content-encoding: gzip
It uses both the LZ77 algorithm and Huffman coding.
The compression is usually done using the Zlib library, which is fast but produces average compression results.
This is the best choice for compressible content with an insecure HTTP server since Brotli compression requires HTTPS.
Gzip compression is also the best choice if maximum compatibility is required, especially for API servers that need to be compatible with old HTTP clients that don't support Brotli compression.
When slow compressions are not a concern (because the compression result is cached), the Zopfli compressor can be used. It's a compressor developed by Google that uses additional compression technics to get better compression results while still producing compatible streams.
Brotli compression
content-encoding: br
Developed by Google, Brotli is an enhanced version of the Zopfli compressor with an optimized format. It uses a dictionary optimized for web content.
It gives better compression results, with speeds falling between Zlib and Zopfli. However, you can sometimes get faster compression than Zlib at the same compression ratio by lowering the compression level. This makes it the obvious choice for compressible content when maximum compatibility is not required.
Why not use deflate?
Deflate is the name of the compression used in both the deflate and gzip HTTP content-encodings.
gzip encapsulates the raw deflate stream in
a gzip container:
- a header of at least 10 bytes, starting with
0x1f8b;
it can include a file name, a comment and extra data. - a footer of 8 bytes: 4 bytes for the CRC-32, and 4 for the decompressed size.
deflate encapsulates the raw deflate stream in
a zlib container:
- a header of 2 bytes starting with
0x78.
- a footer of 4 bytes with the Adler-32 checksum.
Because the deflate content-encoding doesn't actually refer to a raw
deflate compression but to the zlib format, this lead
to confusions resulting in buggy implementations. It's therefore recommended to use gzip instead,
as they are very similar and 12 bytes of extra metadata is not really a problem.
What about decompression speeds?
Decompression with brotli should be at least as fast as with gzip,
and is usually slightly faster (around 5%).
Zlib, Zopfli and Brotli
compression comparison
or
to compress it.
The compression is done in your browser and the file is never sent out or even saved in the browser storage.
Warning: Zopfli compression is quite slow. Be prepared to wait a while for large files.
You can also try it on the wasm file that does the brotli compression, or on the html file of this page.
The comparison tool is available without the explanation text.