Remarkably, the Internet Engineering Task Force approved the Brotli compressed data format specification as an informational request for comment (RFC 7932) in July 2016. Whereby, the Brotli data format is an integral part of the 2nd iteration of the Web Open Font Format.
Well, Google’s zopfli implementation of the deflate compression algorithm is named after a Swiss-German word for a braided sweet bread. And literally means “little plait.” In other words also, Brotli is a Swiss-German word for a bread roll and literally means “small bread.”
So, in general, Google’s own implementation of the Brotli specification was released under the terms of the permissive free software MIT license in 2016. Eventually, the formal validation of the Brotli specification was independently implemented by Mark Adler.
Not forgetting, Adler’s implementation was released under the terms of the similarly permissive Apache license. While on the other hand, other implementations of the specification also exist. Including one in the source-to-source haxe language.
What is Brotli?
By definition, Brotli is a data format specification for data streams compressed with a specific combination of the general-purpose. Like the LZ77 lossless compression algorithm, Huffman coding, and 2nd order context modeling.
For your information, Google employees, Jyrki Alakuijala and Zoltán Szabadka initially developed Brotli. Especially, to decrease the size of transmissions of WOFF2 web fonts. And in that context, Brotli was a continuation of the development of zopfli.
Read Also: Using PNGout to produce amazingly small PNG images
To enumerate, zopfli is a zlib-compatible implementation of the standard gzip and deflate specifications. But, Brotli allows a denser packing than gzip and deflate. Simply, because of several algorithmic and format level improvements.
As well as the use of context models for literals and copy distances; describing copy distances through past distances. In addition, it employs the use of a move-to-front queue in entropy code selection. And also, the joint-entropy coding of literal and copy lengths.
Why is Brotli important?
In short, Brotli is an open-source, lossless data compression algorithm with a better compression density than gzip. Reducing bandwidth consumption and helps content load faster.
First, a modern website and web applications have become more demanding. Surprisingly, web pages now weigh more than ever. And also, bandwidth consumption is at an all-time high. For instance, mobile data traffic alone is expected to go from 7.2 Exabytes in 2019 to 32.6 Exabytes per month in 2020.
In addition, Google, the creator of brotli, says that it’s 20-26% more performant than the other compression algorithm it made called zopfli. Because brotli was open-sourced by Google, the entire online community can benefit.
How do I start with Brotli?
As a matter of fact, in Brotli, there is the use of graph algorithms in block splitting, and a larger backward reference window are example improvements. Above all, the Brotli specification was generalized in September 2015. Particularly, for HTTP stream compression (content-encoding type ‘br’).
This generalized iteration also improved the compression ratio by using a pre-defined dictionary of frequently used words and phrases. Alakuijala and Szabadka completed the Brotli specification from 2013–2016.
Read Also: Zopfli Optimization: Literally Free Bandwidth
Not to mention, the specification was accompanied by a reference implementation developed by two additional authors. Namely, Evgenii Kliuchnikov and Lode Vandevenne. And, who had previously developed Google’s zopfli implementation of the deflate and gzip compatible compression in 2013.
But, unlike zopfli, which was a reimplementation of an existing data format specification, Brotli was a new data format. Allowing the authors to improve compression ratios even further.
How does Brotli work?
At jmexclusives, in partnership with Google, we think that internet users’ time is valuable. And that they shouldn’t have to wait long for a web page to load. Of course, Yes! Because fast is better than slow, and that’s why two years ago the Zopfli compression algorithm was published.
After all, this received such positive feedback in the industry that it has been integrated into many compression solutions. Ranging from PNG optimizers to preprocessing web content. Based on its use and other modern compression needs, such as web font compression.
And as of today, we are excited to announce that we have developed and open-sourced a new algorithm, the Brotli compression algorithm. While Zopfli is Deflate-compatible, Brotli is a whole new data format.
As can be seen, this new format allows us to get 20–26% higher compression ratios over Zopfli. In our study ‘Comparison of Brotli, Deflate, Zopfli, LZMA, LZHAM, and Bzip2 Compression Algorithms’ we show that Brotli is roughly as fast as the zlib Deflate implementation.
At the same time, it compresses slightly more densely than LZMA and bzip2 on the Canterbury corpus. The higher data density is achieved by a 2nd order context modeling. Within the re-use of entropy codes, a larger memory window of past data and joint distribution codes.
Get Started with Brotli
By all means, the smaller compressed size allows for better space utilization and faster page loads. I hope that this format will be supported by major browsers in the near future. As the smaller compressed size would give additional benefits to mobile users. Such as lower data transfer fees and reduced battery use.
Notably, Brotli was first released in 2013 for off-line compression of web fonts. The version of Brotli released in September 2015 by the Google software engineers contained enhancements in generic lossless data compression. With particular emphasis on use for HTTP compression.
Partly, the encoder was rewritten, with the result that the compression ratio improved. And both the encoder and the decoder have been sped up. At the same time, the streaming API was improved. And more compression quality levels have been added.
Additionally, the new release shows performance improvements across platforms, with decoding memory reduction. Brotli uses Huffman coding and a variant of the LZ77 algorithm which allows it to create a sliding window for backreferences.
And while gzip uses a fixed window of 32KB, Brotli uses a sliding window between 1KB and 16MB. This means that Brotli is able to optimize CWND and RWND and deliver larger, compressed files more efficiently.
It also reuses entropy codes and adds a static dictionary that can be referenced from anywhere in the stream.
Start Here: Test your Website Speed and File Size.
Because brotli is open source, it’s freely available as a server add-on to web hosting providers and content delivery networks (CDNs). As well as individuals and businesses that manage their own servers.
Supporting this new compression algorithm doesn’t only save customers of hosting providers and CDNs on bandwidth costs; it also speeds up page load time across the web. As new compression algorithms like brotli emerge, it becomes vital for server owners to adopt them.
And doing so helps declutter and optimize content delivery over the Internet. However, browsers must support this technology as well. You can see which browsers currently support brotli.
How do I enable Text Compression on Server?
Enable text compression on the server(s) that served these responses in order to pass this audit. Configure your server to compress the response with Brotli if the browser supports it.
Although Brotli is a newer format compressor, it does not universally support the browsers. Do a search for “how to enable Brotli compression in
<server>” to learn how to implement it, where
<server> is the name of your server.
Finally, check in the Chrome DevTools for your compressed response.
To check if a server compressed a response:
Command+Option+Jon Mac) to open DevTools.
- Click the Network tab.
- Then click the request that caused your response interest.
- After that, click the Headers tab.
- Check the
content-encodingthe header in the Response Headers section.
To compare the compressed and decompressed sizes of a response:
Command+Option+Jon Mac) to open DevTools.
- Click the Network tab.
- Enable large request rows. See Use large request rows.
- Look at the Size column for your response interest. The top value is the compressed size. The bottom value is the de-compressed size.
Use GZIP as a fallback to Brotli. See Server Configs for example.
Additionally, Gzip can be found on the main GNU FTP server: http://ftp.gnu.org/gnu/gzip/ (via HTTP) and ftp://ftp.gnu.org/gnu/gzip/ (via FTP). It can also be found on the GNU mirrors; please use a mirror if possible.
See also Minify and compress network payloads.
How will Brotli Improve OTA Updates?
Now, OTA updates aren’t served to users as frequently as a Play Store app update, but they do tend to be much larger in comparison. For example, a full OTA package before compression can be 2GBs in size. Just how much data can be saved from an OTA package?
A LineageOS developer for the Motorola Moto G4 reports that they were able to save upto 50 Megabytes on an unofficial build. Considering the fact that the average Moto G4 LineageOS build is about 350 Megabytes, that’s a pretty dramatic improvement.
Read Also: Lighthouse performance scoring
Furthermore, since Brotli also brings improved decompression speeds, that also means that OTA updates can be applied more quickly. So, before the patches can be made via bsdiff, the archive needs to be decompressed.
Since Brotli decompression is rather quick that means decompressing the archive will also be quick, resulting in faster patching of system files. However, users on devices with A/B partition schemes. Such as the Google Pixel/Pixel 2, Essential Phone, Razer Phone, Moto Z2 Force, and Xiaomi Mi A1.
Still, even for these devices, the smaller OTA update package due to Brotli compression will result in reduced bandwidth for the user.
Unlike most general-purpose compression algorithms, Brotli uses a pre-defined dictionary, roughly 120 KiB in size. And, in addition to the dynamically populated (“sliding window”) dictionary.
The pre-defined dictionary contains over 13000 common words, phrases, and other substrings. Derived from a large text corpus and HTML documents. This enables the decoding of mobile phones with limited resources. But, makes Brotli underperform on compression benchmarks having larger files.
The constraints of the small window size can be alleviated by using Large Window Brotli. All in all, which is not compatible with RFC7932 (Brotli proper). Furthermore, streams compressed with Brotli have the content encoding type “br”.
I hope the above-revised guide was useful, but if you’ll have more contribution questions, please Contact Us.