The faster a site is (that’s our core business) the better web user engagement it gets. And there are plenty of solutions to accelerate a website! Reducing page size as far as possible is one of the most effective ways – and the most obvious. Essentially, the fewer bytes that the browser has to download, the faster the site is. And so, one sensible solution involves optimizing the raw size of the JavaScript and CSS code by minifying them, as well as using a more effective compression algorithm.
In this article, we’re not going to be talking about the Swiss German bread, but the compression format. Brotli is the name of the compression algorithm that’s behind the WOFF2 font format for HTTPS traffic, and we’ve put it in place on our platform.
Fasterize now supports this format, so let’s take a closer look at how it works, the benefits it brings, and how to enable it.
Activating Brotli support on Fasterize: stunningly simple
To enable Brotli compression, contact the Support team, who will show you how to do it in just a few minutes, based on your configuration and your CDN, if applicable.
We’ll deal with the new compression format, ensuring:
- pre-generation and caching of file versions compressed using both Brotli and Gzip for all cacheable text resources: cached pages, JS and CSS files;
- and of course content negotiation to serve the Brotli version to compatible browsers.
FIND OUT MORE: HOW WE IMPLEMENTED BROTLI ON FASTERIZE
We’ve chosen to use Brotli exclusively for resources that are intended to be cached with level 9 compression. In addition to this compression, resources are also pre-generated in Gzip at the maximum level for HTTP requests and browsers that don’t support Brotli. We’ll look at the reasons for this choice a little later on, in the section on the technical specifications of the compression formats (oh the suspense...).
This means that the Fasterize cache stores two versions of the same resource, ensuring the Brotli version can be served to compatible browsers.
Note that Fasterize also supports Brotli for communications with the origin server. So, if your origin server supports Brotli, Fasterize will be able to download the Brotli-compressed response and decode it to optimize it. The engine then transmits the Accept-Encoding header announcing Gzip and Brotli support to requests to the origin server.
Brotli vs. Gzip: 1 - 0
THE FIGURES SPEAK FOR THEMSELVES
We carried out a test, and here’s an example of the results we got for one of our clients (Nocibé) through the testing tool developed by Paul Calvano on his blog: a 12% reduction in CSS file size with Brotli!
LinkedIn also carried out a study that demonstrates the improvements that Brotli compression brings, with performance increases of up to 30% with Brotli 11 compared to Gzip 6.
What’s more, Dropbox and Facebook also report compression improvements of 14% to 21%.
Now let’s take a closer look at the technical differences compared to Gzip and what makes Brotli more powerful.
THE TECHNICAL DIFFERENCES BETWEEN BROTLI AND GZIP
Brotli is a lossless compression algorithm that works on the same basis as Gzip (LZ77 and Huffman coding), and was developed by Google. Compared to Gzip, it boasts a better compression rate for several reasons:
- Static dictionary: the Brotli dictionary is part of the implementation and can be referenced at any point in the stream, improving its efficiency for big files. Moreover, transformations can also be applied to the dictionary to expand it.
- Enlarged window size: Gzip uses a fixed window size of 32KB, while Brotli can use a window size ranging from 1KB to 16MB.
- Expanded context modelling: context modelling is a feature that allows multiple Huffman trees for the same alphabet in the same block to suit the context (formats, alphabets, characters, languages, etc.) using three commands (<insert, copy>, <distance>, <lit>).
However, the improved compression rate for the highest Brotli levels (from level 8) also results in a much longer compression time than for Gzip.
For our purposes, the extra time required for Brotli versions 10 and 11 seemed excessive compared to the additional savings and given Fasterize’s scale. That’s why we chose level 9 compression (you can stop holding your breath now).
What’s more, the Squash benchmark shows it clearly: at level 11, Brotli has a compression speed of just 0.51MB/s. This effectively prevents any high-level compression in real time on dynamic resources.
However, level 4 Brotli compression is useful for dynamic compression.
Browsers: which ones support Brotli?
The following browsers support Brotli:
- Chrome supports Brotli from version 49
- Microsoft Edge supports Brotli from version 15
- Firefox supports Brotli from version 44
- Opera supports Brotli from version 36
- Safari supports it from version 11.
However, no version of Internet Explorer (IE) is Brotli-compatible, but the vast majority of Windows users now use Edge, Chrome or Firefox.
The mobile web browser landscape is more fragmented and there is less support.
Levels of Brotli adoption on the web
So what about Brotli adoption across the worldwide web? HTTP Archive offers a way of observing the web from a technological viewpoint. It shows that it is relatively uncommon to see Brotli implemented on the most visited/best-known sites’ servers: in June 2018, just 71% of text resources were compressed. And of those, 60% used Gzip and just... 11% used Brotli.
Why such low take-up? Because it means having to update your server, reconfigure it, etc. – i.e. having to review resource generation processes for upstream pre-generation of text resources.
Another obstacle to the adoption of Brotli is the fact that the format is supported via HTTPS only. This choice was made to avoid compatibility issues and the risk of data corruption with intermediaries such as proxies and content scanners.
And that’s where Fasterize comes in to make your job easier 😉
Curious about our features to improve your site webperf?
