I was inspired by Scott Helme to take another look into Brotli compression for use on the web. As I’m an avid Apache Web Server user, I thought I’d look into the current status of Brotli on home ground.
It has been a little over a year since Google announced its new Brotli compression format named after a Swiss pastry. Brotli is an open standard, RFC 7932, and anyone is free to implement it. So far, several major browsers have implemented it and it has been deployed on a few prominent websites.
Brotli promises big gains in compression but without the increased memory and processing costs that we’ve seen with the other new compression formats that have appeared in recent years.
Almost one year to the date from the original announcement, a patch with support for Brotli landed in Apache Web Server’s (httpd) trunk branch. The new mod_brotli module introduces a new Brotli compression output filter that works like the deflate filter module (mod_deflate) that most webmasters will be familiar with already. The new filter will listen for requests which include the “br”, for Brotli, token in their “Accept-Encoding” and return a Brotli compressed response to compatible web browsers.
The trunk branch, or 2.5.x branch, is httpd’s development branch and means mod_brotli won’t be available until version 2.6. Apache doesn’t follow a stringent separation of versioned branches, and regularly backports new features to their stable branch and on to releases “when they’re ready”. Meaning that we’ll likely see mod_brotli appear in a release of httpd 2.4.x and won’t have to wait years for httpd 2.5.x to benefit from Brotli compression. There’s no roadmap for the httpd project, but my best guess is that mod_brotli wouldn’t appear in a stable release until some time in 2017. Assuming it doesn’t cause any problems in testing, of course.
There are some signs that the popular Nginx web server is moving to add Brotli support, but no code has surfaced yet so httpd beat them to it.
Brotli now
If you’re impatient and want to deploy Brotli on your website today, you’ve a few options:
If you’ve a static website and resources, you can rely on HTTP content negotiation and pre-compressed resources. Content negotiation will take care of serving visitors the correct compression format based on their browser’s capabilities. The blog collective Lyncd have written up a tutorial on adding Brotli for static resources in httpd.
If you need output filtering for a dynamic website but can’t wait for the official mod_brotli release, you can use brotli_module by KJdev. brotli_module is an independent implementation compatible with httpd.4.x. You’ll need to install httpd development packages and manually install the module in your Linux distribution of choice.
I gave brotli_module a go, and found that Ctrl blog’s home page weighs about 35 473 bytes without compression, 6438 with gzip (81,85 % reduction), and 5112 with Brotli (85,59 % reduction.) I also got a nice 5 % decrease in average memory consumption by my httpd worker processes. There are many articles already getting into the nitty-gritty of performance and comparisons of Brotli to other compression standards, so I’ll not go into more details as I don’t believe I’ve anything more to add to this discussion.
Were are we at with Brotli adoption?
Browser-wise, the adoption of Brotli compression has been quite swift. Firefox, Chrome, and many Chromium derivative web browsers have had support for Brotli for some months already. Microsoft Edge have committed to supporting Brotli in a future release, but there haven’t been any word from WebKit/Safari yet. Given that all the other browsers have already implemented Brotli, WebKit will probably follow suit at their own pace. Lighter websites mean longer battery life for devices, so Apple will probably introduce it as a magical new battery experience someday at one of their press events.
A Brotli compatible web browser will include the br token in the Accept-Encoding request header. Google has arbitrarily decreed that this header should only be sent in HTTPS streams. There’s no technical justification for requiring the use of HTTPS to use Brotli other than Google’s desire to push their agenda to encrypt the web. I don’t mind nor disagree with Google’s stance on this, but I believe it ought to be mentioned whenever they use their market position as political pressure in the industry.
Google’s own web properties such as Google Search and YouTube currently don’t serve Brotli compressed resources. Google is often quite conservative with adopting new technology – even their own standards – on their web properties. The largest website to deploy Brotli is currently Facebook.