Compression: Making the Big Smaller and Faster (Part 2)
Learn about the Brotli Compression in comparison to other compression algorithms and how you can make the big smaller and faster with compression.
Join the DZone community and get the full member experience.Join For Free
in the last blog, we discussed the different methods of compression and how it works. in this post, we are going to talk about the brotli compression in comparison to other compression algorithms.
per rfc7932 : brotli is a lossless compressed data format that compresses data using a combination of the lz77 algorithm and huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.
it’s maintained by google and reduces bandwidth consumption and helps content load faster.
when it was developed in 2015, brotli was used to compress fonts in the woff2 (web open font format). with time, its popularity increased and now it’s even used for compressing/decompressing textual data. brotli has a direct effect on page load times by reducing the page size and ultimately the bandwidth consumed.
this compression algorithm is now supported by many browsers as a new accept-encoding scheme that can be used to compress static web page assets.
brotli: browser support
how to check if a browser supports brotli
most browsers that support brotli compression advertise their ability to accept brotli-compressed resources in the accept-encoding request header.
the accept-encoding request http header advertises which content encoding the browser understands. using content negotiation, the server selects one of the proposals and informs the client of its choice with the content-encoding response header.
here is a screenshot of http request-response headers captured from an instant test run for a website that supports brotli compression.
the instant test was run using chrome version: 53.
if you observe the request headers section, you will notice that the browser sent an http request advertising the encoding schemes it supports.
accept-encoding: gzip, deflate, sdch, br
the response headers section clearly shows that the web server supports brotli compression.
google turned on the support for brotli with its release of chrome 51 in may 2016. firefox had added support for brotli as early as september 2015.
since brotli is another compression algorithm, like g-zip, let’s have a look at how each of the compression algorithms fair when tested for css, js, and a jpeg resource.
let the comparisons begin. in this case, we are plotting the compression ratio comparing brotli and g-zip.
compression ratio is calculated using the formulae: uncompressed size/compressed size. a 10 mb uncompressed file compressed to 2 mb, the compression ratio will be 10/2 = 5. the lower the compression ratio, the better is the compression method.
- css resource : link .
- image file : jpeg file; file size: 4.23 mb.
a very important factor when it comes to benchmarking compression algorithms is decompression speed. how quickly browsers can decompress the compressed content at their end determines how strong the compression algorithm is.
when it comes to decompression speed as well, brotli performed better than g-zip, reporting faster decompression times for the same js, css, and jpeg files.
compression speed is an indicator of how quickly the algorithm could compress the content. the less time it takes to compress, the better the algorithm.
i would say no. it is not advisable to judge or benchmark compression algorithms simply by comparing the bytes saved. here’s why:
- g-zip offers nine quality levels of compression . lower quality levels such as one or two will result in extremely fast compression but will not result in a lot of file savings.
- using a quality level of nine will improve the compression quality and will result in greater file saving, but the compression speed will be slow .
- g-zip offers nine quality levels whereas brotli offers 11 . the higher the quality level, the better the compression and slower is the compression speed.
- g-zip by default uses a quality level of six, which has been optimized for speed as well as efficient compression . brotli, on the other hand uses the maximum available quality level of 11 which results in unbelievable compression quality but is slower. please note that the tests were run at the default quality settings for both g-zip and brotli.
- it is recommended to tweak the quality levels of the compression algorithm you're using (either g-zip or brotli) based on your requirements to achieve efficient results.
future of brotli
g-zip has been around for the past 19 years whereas brotli as a compression algorithm was introduced only a couple of years back. brotli may not be as big as a game changer when compared to the features that http/2 may have to offer but it still is a game changer. with websites getting complex with each passing day, with the #items loading to serve a webpage increasing day by day, every second and every byte saved makes a difference to the overall end user experience.
with the default compression setting of 11, brotli may not be a good pick when it comes to compressing dynamic content on the fly. these settings, however, can be tweaked to achieve a balance between compression speed and compression quality.
brotli is supported by all major browsers out there including google chrome, mozilla firefox, edge and opera.
according to google: “the amp cache, which stores slimmed-down web pages on google’s servers, now uses google’s brotli compression algorithm to reduce document size by 10 percent in supported web browsers, and compresses images 50 percent more efficiently without affecting quality.” this was announced in google i/o 2017. amp or accelerated mobile pages is a google project. you can see the keynote here .
companies like microsoft and linkedin have already started to experiment with brotli and this a positive step towards the overall development and adoption of “brotli” as an efficient compression algorithm and the future of this compression algorithm; named after a “swiss bakery product” looks bright.
all tests to compare the performance of g-zip and brotli were run using “r” on a computer with the following specifications: processor: intel(r) core(tm) i7-6600u cpu @ 2.60ghz, 2808 mhz, 2 core(s), 4 logical processor(s); ram: 8.00 gb.
Published at DZone with permission of Nilabh Mishra. See the original article here.
Opinions expressed by DZone contributors are their own.