mod_bortli for WordPress

New Brotli compression filter module now in Apache Web Server

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 their 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 includes the “br”, for Brotli, token in their “Accept-Language” and return a Brotli compressed response to compatible web browsers.

The trunk branch, or 2.5.x branch, is httpd’s development branch. 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 is no roadmap for the httpd project, but my best guess is that mod_brotli wouldn’t appear in a stable release until early next year. 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 have a few options:

If you have 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 Slight Future’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 have 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 have been no word from WebKit/Safari yet. Given that all the other browsers have already implemented Brotli, WebKit will probably follow suit at their own pace. Smaller websites means longer battery life for devices, so Apple will probably introduce it as a magical new battery experience some day at one of their press events.

A Brotli compatible web browser will include the br token in the Accept-Encoding request header. Google have arbitrarily decreed that this header should only be sent in HTTPS streams. There is 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.

Sources

6 thoughts on “New Brotli compression filter module now in Apache Web Server”

    1. “Replacing deflate with brotli typically gives an increase of 20 % in compression density for text files, while compression and decompression speeds are roughly unchanged.” via Wikipedia.

      There are community modules for IIS and nginx floating about the web too.

  1. I wrote an article about this on Smashing Magazine. The takeaway is that you need to do your own testing, but I provide some figures on performance vs gzip on all configurable compression levels.

    I use it on my own website, and there seems to be a benefit. If nothing else, it’s transferring less data over the wire, which would be more courteous to those on restricted data plans.

    1. That is an interesting concept. However, accessibility is terrible and what ever happen to mobile responsive PNG? My website is gets a web bloat score of 0,4 with my own ad system or 2,15 with Google ads. So, yeah. Says a lot about

Leave a Reply

Your email address will not be published. Be courteous and on-topic. Comments are moderated prior to publication.