Brotli is a new compression algorithm being introduced by Google. It’s gaining traction very quickly - there’s an IETF draft proposal for the data format. There are even plans to include Brotli as an accepted
Content-Encoding in Firefox 44:
Brotli is being touted as an alternative to gzip, offering comparable decompression speeds. In the article announcing the new algorithm, Google claims that:
This new format allows us to get 20–26% higher compression ratios over Zopfli.
But does the format actually live up to the hype? I decided to find out by comparing it with other commonly used compressors.
I created a tarball (
test.tar) from the following files:
- the source code for NitroShare
- a Python script (3.4 KB)
- a PNG screenshot (19.7 KB)
- a 2 second WAV file (459 KB)
The total size of the tarball was
5,079,552 bytes (5.1 MB). For each compressor, my goal was to measure the size of the compressed output, the compression time, and the memory usage during compression. The table below includes the command I used and the metrics for each:
|Command||Size (bytes)||Time (seconds)||Memory (KB)|
* compression presets higher than 6 only apply to files larger than 8 MiB
The results are not what I expected. The best compression ratio was still acheived by LZMA, offering a ratio of 7.24:1 compared to Brotli’s 6.75:1. In exchange for this, Brotli took over 9.3x longer and used 3.79x as much memory (almost 250 MB). Clearly it offers no improvement when it comes to compression.
But what about decompression?
|Algorithm||Time (seconds)||Memory (KB)|
Brotli is right on par with LZMA when it comes to decompression speed, although it uses 175% more memory. The big question is whether this extra memory usage would be acceptable on a web server.
In summary, Brotli offers some interesting numbers and much better compression ratios than
gzip but at the expense of drastically increased memory usage and much longer compression times.