In terms of front-end performance optimizations, one of the most common is to enable gzip compression to reduce resource size, but is there an alternative to gzip for Content-encoding? What do the other options mean? Today we are going to take a look:

A few days ago, I read ruan’s technology enthusiast weekly, and mentioned that NGINX official wrote an article on how to reduce Internet traffic through NGINX configuration, which mentioned enabling Gzip, so I thought to check whether my vislib.best has opened gzip. It turns out that gzip isn’t really open, but… What is this BR?

vislib.best

So look it up:

The five values of Content-encoding mentioned in MDN are gzip, COMPRESS, Deflate, identity and BR.

  • Of these, GZIP is the most commonly used, as we all know, and the format supported by GZIP in Unix, and this format is deflate.
  • Compress is a Unix compress program that has been removed from most Unix distributions and is no longer supported by many browsers because the author of compress patented the algorithm. There is a copyright fee to use this algorithm, so it is gradually replaced by Gzip or Deflate, and gzip is now dominant even though the original patent has expired.
  • Deflate is based on the Deflate compression algorithm, which is also used in our common ZIP compression packages and PNG image formats. Since Deflate uses the same compression as Gzip, what’s the difference between deflate and Gzip? In fact, in terms of compression algorithms, there is no difference between the two, the main difference is that the checksum algorithm and data format are different.
  • Identity indicates that the content is not compressed, and is the default if content-encoding is not set.
  • So what is BR? MDN explains that this is a format that uses Brotli, a compression algorithm specifically designed for HTTP Content-Encoding that was invented and implemented by Google engineers between 2013 and 2016, The BR format was supported by all major browsers and servers around 2016-2017.

In addition to the five formats mentioned on MDN, there are several other official and unofficial formats, which I won’t cover here. If you are interested, check out the wikipedia entry.

Now let’s compare these compression formats,

Why is Gzip more widely used than Deflate in the first place? The compression algorithm is the same, and deflate is actually faster than Gzip. According to a note on StackOverflow, this is because many browsers have implemented deflate incorrectly for years (Nani?? As a result, the implementation logic of this algorithm is complicated and often fails on many browser versions, so deflate is also not recommended.

Since gzip and Deflate actually use the same compression algorithm, the next step is to compare Gzip to BR.

I won’t do the specific experiment, but post the data of others:

Checking the top 1000 URLs on the internet, brotli performance is: 14% smaller than gzip for JavaScript 21% smaller than gzip for HTML 17% smaller than gzip for CSS

You can see that BR performs significantly better than GZIP. Here only the compression rate, of course, but we know that measure the performance of a compression algorithm compression ratio is just on the other hand, compression speed is also very important, after all, the goal of improve the compression ratio is in order to reduce the time of data transmission, if transfer time was saved, but spent more time on the compression, that doesn’t make sense.

Of course, experiments have been done in this regard, and the specific experimental data are posted below:

The first column is the compression algorithm, and the brackets are the levels of the compression algorithm, among which brotli has 11 levels and gzip has 9 levels. For each algorithm, the higher the level is, the better the compression effect is, but the compression speed is correspondingly slower. The second column is the ratio of compression, the third column is speed, and the fourth and fifth columns are the difference in compression speed and size from the gzip default level(Level6). Brotli level4 is the most balanced compression ratio and speed.

But compression speed is not so important for us, why, because our static resources mostly adopt the way of CDN load, so in general static resources need compression only once, and then our CDN will keep the resource cache compressed, then distribute resources when there is no need for compressed again, Therefore, CDN usually adopts the level with the highest compression efficiency to compress. Of course, if it is for the compression of dynamic resources without CDN, the highest level is not the best choice. In this case, Brotli algorithm of Level 4 is more appropriate.

Brotli has better compression performance than Gzip for both static and dynamic resources. According to Caniuse, Brotli is compatible with the following browsers:

And even if some browsers don’t support this format, the server can provide degraded processing and distribute gzip-compressed resources according to the accept-encoding set by the browser, so feel free to turn on Brotli on your site.

So how do you open Brotli?

If your static resources are loaded using A CDN, check with your CDN provider to see if it supports them. For example, CloudFlare can find the option to enable Brotli in Speed Optimization.

If you want to configure Brotli in NGINX, refer to this document.

There are also some interesting discussion articles about Brotli and gzip on the web. This article is based on those articles, so it’s posted below for those who are interested:

Blogs.akamai.com/2016/02/und…

Stackoverflow.com/questions/3…

Expeditedsecurity.com/blog/nginx-…

www.alonehero.com/2019/10/13/…

www.freeoa.net/scheme/depl…