Measuring the Effects of Brotli Compression on WordPress

WordPress is a great CMS for a variety of reasons. It’s easy to use, has a great community, is configurable, and much more. However, one thing that WordPress users seem to struggle with quite often is the performance of their WordPress site. This post will take a look at Brotli Compression, and its effects on the performance of WordPress.

Disclaimer: I work for KeyCDN and have referenced a couple of their articles and tools here.

There are many “Speed up WordPress posts” available online that provide great insight into how to improve the loading times of your site using a variety of methods, including optimizing via plugins. However, since Google’s release of their newest compression algorithm – Brotli, there hasn’t been much data collected to determine what sort of performance improvements one might experience from enabling it on a WordPress site.

In this article, we’re going to be measuring the effects of Brotli compression by testing WordPress performance under three different scenarios:

1. WordPress with Gzip enabled
2. WordPress with Brotli enabled
3. WordPress with Brotli enabled + a Brotli-supported Content Delivery Network

What Is Brotli Compression?

Named after a Swiss bakery product, Brotli is a relatively new compression algorithm released by Google back in 2015. According to Google, Brotli compression uses a combination of a modern variant of the LZ77 algorithm, Huffman coding and 2nd order context modeling.

Google has performed various tests using the Brotli compression algorithm and has benchmarked the results against other modern compression algorithms. Based on this study, Google found that Brotli outperformed Zopfli (another modern compression algorithm) on average by 20-26% in terms of the compression ratio. When it comes to performance, having your files compressed to be smaller in size is always welcome.

Install and Configure Brotli on Your Server

One of the minor downsides of Brotli is that it is not yet officially distributed on any popular web servers. This means that if you want Brotli enabled on your server today, you’ll need to do a bit of your own configuration work. For the following Brotli performance tests, everything was carried out on Ubuntu 16.04.2 LTS running Nginx (Need to learn about using Nginx? Check out the SitePoint Premium course Faster Websites with Nginx). Below, we’ll step through the process of how you can get Brotli up and running using the same OS and web server.

Ubuntu 16.04 is the first Ubuntu distribution that allows you to install Brotli using apt-get. To do this simply run:

$ apt-get update && apt install brotli

Once that is complete, you’ll need to install the Nginx module for Brotli compression and compile the latest version of Nginx (currently 1.13.0):

$ git clone --recursive https://github.com/google/ngx_brotli ngx_brotli

$ wget http://nginx.org/download/nginx-1.13.0.tar.gz
$ tar zxvf nginx-1.13.0.tar.gz
$ cd nginx-1.13.0

$ ./configure --add-module=../ngx_brotli
$ make && make install

Brotli should now be properly installed on your server. Next, you’ll need to configure your nginx.conf file to specify your desired configuration directives. The following directives were used for the purposes of these performance tests; however, you can modify them as you see fit.

Brotli Settings

brotli on;
brotli_comp_level 3;
brotli_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

A full list of directives can be found on Nginx module Github page.

Since the nginx.conf file was modified, the last step is to reload Nginx. To do this, run the following command:

systemctl reload nginx

Testing Brotli Support

Brotli should now be installed and configured on your server. To verify this, you have two options.

1. Use a Brotli test tool that will check based on a domain whether or not the server supports Brotli.
2. Using the Chrome browser, open Chrome dev tools and navigate to the Network tab. Refresh the page and select one of your assets. You should see that the value for content-encoding is now br which stands for Brotli.

Configuring Brotli to Work with WordPress

At this point, you should be able to properly deliver your WordPress assets using Brotli compression. However, if you check the request header details for the HTML doc, you’ll likely notice that the content-encoding value is still “Gzip”. This is due to WordPress PHP code which relies on the PHP setting `zlib.output_compression` “On”.

Unfortunately, this is not something that can be changed using a WP filter at the moment. However, as Brotli popularity continues to grow, perhaps WordPress may introduce a simple fix. At the moment, you will need to disable zlib.output_compression manually, by editing your php.ini file (located at /etc/php/7.0/fpm/php.ini if using PHP 7.0). Simply set zlib.output_compression = Off and restart PHP using systemctl restart php7.0-fpm.service.

You should now be able to see the content-encoding header value br when checking your site’s HTML doc.

Brotli Performance Testing on WordPress

As mentioned above, our Brotli performance tests were performed under three separate scenarios.

1. WordPress with Gzip enabled
2. WordPress with Brotli enabled
3. WordPress with Brotli enabled + a Brotli-supported CDN

Both Brotli and Gzip compression levels were each set at “3”. The compression levels can be modified based on the amount of file savings vs compression time you prefer. Each test used a vanilla WordPress installation running the “2017” theme. By default, this theme loads 14 resources and transfers 236KB worth of data.

It should be noted that not all assets within the above test site are compressible. For example, images are not compressed by either Gzip or Brotli and any third-party assets such as fonts will not be compressed by Brotli either. Therefore, the baseline for the total size of all compressed asset with Gzip is 84.7KB. To account for loading time variations, we hard-refreshed the page three times each and calculated the average load time for each test scenario. This way, all assets were loading from the server, instead of from browser cache.

The following table outlines the results of what was found for both loading speeds and compressed asset sizes.

	WordPress Gzip	WordPress Brotli	WordPress Brotli + CDN
Loading Speed	780 ms	690 ms	630 ms
Compressed Size	84.7 KB	81.7 KB	81.7 KB

As we can see by the results, both cases of Brotli compression resulted in faster load times and smaller compressed size than Gzip. Although the difference in page size isn’t drastic, remember that these tests were performed on a bare-metal WordPress installation. For those who have sites with many resources, small savings on multiple assets will certainly add up.

Additionally, for testing purposes, we set both compression methods to their highest levels to observe the difference in compressible asset size. The results were as follows:

• Brotli 11 – Compressed size: 67.7 KB
• Gzip 9 – Compressed size: 76.7 KB

Although in both cases setting the compression levels to max may not be necessary (due to much higher compression times) it’s interesting to note that the compressible asset size of the Brotli site was 13.2% smaller than the compressible asset size of the Gzip site.

What’s the Status of Brotli Support?

Brotli isn’t universally supported yet on all browsers, although a good number of popular browsers do currently support it (as of May 2017).

http://caniuse.com/#feat=brotli

As for server support, most popular web servers either offer an official or community-created module. As shown in the installation process of this article, Nginx users must install an extension and compile Nginx with Brotli support. Similarly, Apache users can implement the mod_brotli module to deliver Brotli compressed content.

Pros vs Cons of Brotli

Like anything, there are still pros and cons to using Brotli. Below are a few points to consider.

Pros

• Smaller compression results
• Faster load times
• Comparable compression times to Gzip

Cons

• Currently a bit cumbersome to adopt
• Non-universal browser support
• Manual configuration required to fully implement with WordPress

Additionally, Brotli can only be used over HTTPS, which can be seen as both a pro and a con. On one hand, it’s helping more sites move from HTTP to HTTPS, creating a more secure internet. While on the other hand, it introduces more work for those who want to enable Brotli but are still using HTTP.

Summary

As shown in the test results, the outcome of implementing Brotli on a WordPress site is quite beneficial in terms of performance. Implementing Brotli on the origin server allows the compression to take place on the server side and then caching that content on a CDN that supports Brotli compression allows for even faster asset delivery.

Although Brotli isn’t yet universally supported by all browsers, it’s important to recognize which browser(s) your visitors are using most and catering to them by providing even faster load times. Furthermore, for those using browsers that aren’t yet supported, those browsers will simply fallback to using Gzip – a win-win.

Frequently Asked Questions (FAQs) about Brotli Compression for WordPress