Deflate and GZip compression have been with us on the web for many years. They do a decent job but as times move on, so do compression algorithms. This is something I have talked about before using services like TinyPNG to squeeze the spare bytes out of your images to reduce page load times but this only applies to images obviously.
Brotli is a Google project for a newer, more modern compression algorithm for the web. According to the claims of Google, using Brotli over GZip not only increases the content compression reducing page size but also reduces CPU usage in the decompression process too. With the ever expanding usage of mobile devices, both of these are great things to have.
If you are interested in reducing your page size to improve load times and reduce your outbound bandwidth on your site then read on to learn now. I will cover the requirements, fallback compatibility and also how to get Brotli for Linux and Windows as well as the main point, how to enable it for an Azure Web App.
Brotli Requirements
Implementing Brotli support requires three elements. One, the server must support the compression type and two, the browser on the client must understand it to decompress the content. Brotli is supported in Chrome 49, Firefox 44 and Opera 36 and above. It is also supported in Microsoft Edge as of build 14986 of Windows 10.
The third element is HTTPS. Some browsers are currently accepting Brotli compression over HTTP but per the design, it is only meant for HTTPS use. Microsoft for example are dropping the HTTP Brotli support in a future release.
Brotli Fallback
When Brotli is implemented on the server-side and a client connects which does not support it, the client will simply not see or use the Brotli Response Header and will continue to use GZip or Deflate as normal which means it degrades nicely for legacy clients. For example, a user using an older build of Chrome or a user using Internet Explorer will continue to see and use GZip compression without any effects on them from implementing Brotli.
Brotli on Apache or nginx
The topic of focus here is Azure Web Apps so I will gloss over Apache or nginx for Linux folks. The crux of the matter is that there is no native support but there are installable modules to add support from https://ayesh.me/apache-brotli for Apache (note that the Apache module is quite DIY) or from https://github.com/google/ngx_brotli for nginx.
Brotli on Windows Server IIS
If you are running on-premises or using an IaaS VM in Azure, AWS or elsewhere, you can install the Brotli Module for IIS 7 or above. You can get the module for IIS from https://www.iis.net/downloads/community/2016/03/iis-brotli.
Brotli on an Azure Web App
This is the main purpose of the article, but I wanted to just touch on the other platforms quickly first. Because I wasn’t entirely sure how the implementation was going to work, I did this against a test site in Azure which had no existing configuration or live website running against it. I would recommend you do the same to test it for yourself before going ahead and poking your live site with the changes.
First, login to your Microsoft Azure portal and open up the blade for the Web App that you wan to configure. From the Web App blade, select the Application Settings blade.
On the Application Settings blade, we don’t need to change anything but we do need to check something. Check the value for Platform. As you can see above, my site is 32-bit but yours may be 64-bit. I used to use 64-bit until someone showed me this article by Scott Hansleman, Penny Pinching in the Cloud.
Once you have the architecture for your site, scroll down the list of Web App blades and open the Extensions blade.
On the Extensions blade, select the Add button and scroll through the list until you find the extension Brotli HTTP Compression. There are two variants of the extension, one for 32-bit and another for 64-bit. Select the appropriate one and then accept the legal terms to add the extension to the site.
Once you have added the extension, I found that it didn’t work right away and I needed to restart the Web App for it to take effect. This may not always be the case but it certainly my observation.
Testing the Brotli Implementation
To test your Brotli implementation is pretty simple and you can do it using either a tool, manually or both. I tested both just for completeness.
There is a tool available from KeyCDN at https://tools.keycdn.com/brotli-test. Simply enter your URL, remembering that Brotli is designed for HTTPS so use a secure URL. Here is the before and after image for my test site. The first image is before I added the Brotli site extension and the second is after.
For the manual test, I used the Developer Tools in Chrome to view the response headers coming back from the site page load.
In the first image, we can see that the header Accept-Encoding lists gzip, deflate and sdch are available to use.
In the following image after enabling Brotli support on the site, we can see that in addition to the existing types for Accept-Encoding, we now have the br type added.
Comparing Brotli to GZip
All of the above has been done using a newly created Azure Web App test site but how does Brotli stack up against GZip in the real-world on a production site. Bearing in mind, I have done nothing to the site or the contents except enable Brotli so the results are simply just from enabling the option.
In the first image below, we can see that the home page https://richardjgreen.net generated 35 HTTP requests with a total of 474 KB of page weight which took 4.64 seconds to load.
After enabling Brotli, I did the same, loaded the home page but I did using an Incognito Mode session so that anything in the cache and temporary internet files was hidden. In this test, we can see that there is still 35 HTTP requests generated but this time, the page weight was down from 474 KB to 429 KB purely as a result of Brotli. The page load was much faster which I am not putting down to Brotli and I think must have been some client slowness in the initial test.
So there we have it. Enabling Brotli and doing nothing more has resulted in a reduction of page weight of 45 KB. That may not seem like a lot per page load however if you consider that this blog receives roughly 4,000 page views per month, when that is multiplied out, that is an outbound traffic reduction of 180,000 KB per month or 180 MB per month. If you had an image heavy site with a larger page weight or a site receiving tens or hundreds of thousands of views per month, that could easily save you the order of gigabyte not megabytes per month.
When we remember that in Microsoft Azure, we pay for outbound traffic from the datacentre, if your site is pushing a lot of traffic then this could actually turn into savings for you as well as improved performance for end-users so a double win.
UPDATE 7th August 2017: Microsoft has now embraced Brotli and it is available to use in the latest preview builds of .NET Framework and .NET Core as per https://www.neowin.net/news/microsoft-endorses-googles-brotli-compression-algorithm-announces-alpha-preview-for-net. Fingers crossed, we may see IIS native support for Brotli in the future.