Brotli, a better Gzip

For serving assets on the Web, it is a good idea to compress the file contents that are served to users.

Better compression means fewer bytes transferred, which means faster page loads.

Gzip is the standard compression method for the web. Practically every browser supports Gzip compression.

Here Comes A New Challenger

Brotli has emerged as an improvement over Gzip.

It is a better compression algorithm, and great for the Web.

Browser support for Brotli has gotten to be very good, with 96% support at time of writing.

Testing Brotli Out

To directly compare Brotli to Gzip, let’s do a test run.

We can use the “Complete Works of William Shakespeare” from Project Gutenberg.

That gives us a nice plaintext test file that is just over 5 megabytes in size.

We can compress this file with both algorithms to compare them.

Compression Ratio

Brotli and Gzip both support compression “levels”, which tune compression density, but also the computational cost.

For Brotli the --best compression is level 11.

For Gzip, --best is compression level 9.

Lower levels result in larger output file sizes, but can be faster to compress the inputs.

Let’s compare the size results of recompressing our Shakespeare input across levels, for both tools:

Compression ratio by level

Compression ratio by level — Shakespeare1234567891011compression level5048464442403836343230ratio (%)

We can see that Brotli consistently compresses this file to be much smaller than Gzip, at the same compression level.

At level 9 (the highest compression level for Gzip) we see Brotli results in 15% smaller final filesizes than Gzip.

And at level 10 and 11, we can see Brotli perform even more aggressive compression, saving an additional 5-8% on final filesize beyond level 9.

Over millions of requests, this can mean many fewer bytes transferred to users.

Compression Time

But this better compression does not exactly “come for free”.

As a test, let’s recompress Shakespeare 10 times, across each level and take the median1.

We find a surprise about the computational cost of the highest Brotli levels, 10 and 11.

Compression time by level

Median compression time by level — Shakespeare (10 runs/level)1234567891011compression level9876543210time (s)

The highest Brotli compression ratios require significantly more computational time to compress.

Most compressions of our Shakespeare input complete in under one second, with both algorithms.

But the time required to compress inputs at quality 10 jumps up to nearly 4 seconds, and 8 seconds for quality level 11!

Conclusions

Brotli is just better, flat out.

However, most but not all browsers support the encoding. Make sure to respect the Accept-Encoding header, and only return Brotli compressed assets if the client supports decompressing them.

Generally, the compression time for assets is a non-issue, and we simply want to save as many bytes transferred over-the-wire as possible. The time for clients to fetch and load assets is the real saving.

But as a warning, the Brotli compression at the best quality levels is significantly slower than at level 9 and below. Make sure to check and profile your CI and deployment environment if using the most aggressive compression.

It may be the case in your situation that the extra compression time is not worth the additional 5-8% savings.

Footnotes

Footnotes

  1. The spread in median time taken (on my i7 with a fast SSD) was very low, around 1-5% at each level. ↩