The Problem Statement
Everyone is trying to find new ways of increasing the performance of their website. Increased performance means content is loaded quickly onto the screen.
For that to happen, so many methodologies and concepts like Caching, Minification tools, Service Workers, CDN, e.t.c are in place.
Even when the code is minified, there is still a lot more KBs that are being sent over the network to the browser. One way to tackle this problem is to introduce Web Compression.
2 main algorithms that are out there to do this job - GZIP and Brotli.
How Web Compression Works
The idea is simple.
- Any properly configured web server sees that you are sending a plain text data.
- Before sending it out, the server compresses it via an algorithm and sends it across to the browser.
- Any properly configured browser will detect that the content that was sent is compressed.
- The browser will then uncompress the data and execute it.
This process reduces the size of data travelling between the browser and the server which results in speed gains which over compensated the milliseconds lost in compression and decompression.
Many browsers of today are well equipped to decompress the compressed data received from the server. But it isn’t the case with all browsers.
Browser needs to tell the server that it is well-equipped to handle certain encoding and decoding algorithms. It does that by sending a special header along with the request - accept-encoding
accept-encoding: deflate, gzip, br
where deflate is another web compression algorithm like gzip and brotli (br).
Brotli is faster than Gzip
Brotli is newer and faster than an already fast encoding solution Gzip.
Gzip was released back in 1992, just before web became publicly available.
Brotli, the relatively newer algorithm which was released by Google in September of 2015, has pretty much become the standard in many of the web browsers and servers.
Here’s how fast Brotli is compared to Gzip. It results in -
- 14% smaller JavaScript files.
- 21% smaller HTML files.
- 17% smaller CSS files.
It can decompress the entire Front End 64% faster than Gzip.
Other than all this - Brotli was designed to compress streams of data at the server end, wherein each file (JS/HTML/CSS) is an individual stream. This results in higher speeds than just compressing the entire files at server end before sending them across the network to the browser.
How will the browser know the encoding used
Non plain text file like images are already encoded, hence the server doesn’t need to encode them further and can send them across the network as it is.
Along the text files that are sent across compressed or encoded, a special header is sent -
Content-Encoding: br
which lets the browser know what encoding mechanism has been used to compress the particular file or stream of data so that the same can be used to decompress it.
Just another thing - No versions of Internet Explorer supports Brotli.
Some technical details on how Brotli works
Brotli uses a concept called dictionaries which are nothing but a set of key value pairs that can be used as references to encode and then decode the code later.
Gzip doesn’t uses dictionaries whereas Brotli uses 2 - static and dynamic.
Static dictionary contains common references used amongst HTML/CSS/JS code which can point to a larger piece of code.
Dynamic dictionary uses a sliding window which can be upto 16MB in size which acts as a cache for all the recent common references being used in the code, and its always changing.
This same cache or sliding window in Gzip is about 32KB in size. And that’s why Brotli uses more CPU power than Gzip to provide a higher compression ratio that Gzip.
