Understanding and using mod_brotli for web compression

Enhancing website performance is crucial, and one effective method is using compression to reduce the size of files transferred between your server and visitors’ browsers. While GZIP has been a long-standing standard, Brotli is a newer compression algorithm designed specifically for the web.

Brotli was developed by Google employees. Google released the Brotli specification for HTTP in 2015. Google engineers also made other improvements to Brotli that made it even faster for compressing web content.

Brotli vs. GZIP

Understanding the difference between Brotli and GZIP is key to appreciating Brotli’s benefits. GZIP was designed specifically to compress files. Brotli, on the other hand, was specifically designed for the web. Google recognized the need for a way to compress streams more efficiently, which led them to design Brotli.

While Brotli is not the most compressive option available overall, its main tenant is to get the fastest decompression from the highest level of compression. It’s actually overall slower than GZIP at the initial compression, but usually beats it when decompressing the source. The underlying idea is to offload work from the client so they see a site that renders slightly faster. Brotli is faster at decompressing than GZIP. When a browser supports Brotli, it notifies the server by sending a “Content-Encoding: br” header.

Compression benchmarks

To illustrate the difference, the source performed a rudimentary test using a file named media-views.js which was 227K in size.

For Brotli compression, the following command was used to time the process on this file:

time brotli media-views.js

The result showed a real time of 0m0.985s for Brotli compression. The resulting compressed file media-views.js.br was 37K in size.

For Gzip compression, the following command was used to time the process on the same file, aiming for the best compression:

time gzip --best media-views.js

The result showed a real time of 0m0.016s for Gzip compression. The resulting compressed file media-views.js.gz was 45K in size.

In this test, Brotli was significantly slower at compression (0m0.985s vs 0m0.016s), but achieved a smaller file size (37K vs 45K).

Decompression benchmarks

The source also compared the decompression speed of the compressed files.

For Brotli decompression, the following command was used to time the process:

time brotli -d media-views.js.br

The result showed a real time of 0m0.003s for Brotli decompression.

For Gzip decompression, the following command was used to time the process:

time gunzip media-views.js.gz

The result also showed a real time of 0m0.003s for Gzip decompression.

In this specific test, the decompression times were nearly identical (0m0.003s for both). However, the source notes that typically Brotli is faster at decompressing than GZIP.

Conclusion

Based on this rudimentary test, the compression time was a little slower with Brotli but offered better compression (smaller file size). Despite the slower compression, decompression was (marginally) faster in this specific test. Scaling this up to hundreds of thousands of requests, even marginal savings in decompression time and bandwidth from smaller file sizes could be worthwhile. The idea is to shift the computational cost from the client (browser) to the server during compression, so the client benefits from faster decompression and less data transfer.

Was this article helpful?

Thank you for your input.

Thank you for your feedback.