content-encoding 除了gzip以外，你还知道哪些？

关于前端性能优化，咱们都知道常见的一条是要开启gzip压缩，减小资源体积，可是，content-encoding 除了gzip还有别的选择吗？另外的几项选择都是什么意思呢？今天咱们就来捋一捋：

前几天看阮老师的科技爱好者周刊，提到NGINX官方写了一篇文章介绍如何经过NGINX配置减小互联网流量，其中讲到开启gzip，因而我想起去check一下本身的 vislib.best 开gzip了没有。结果发现，居然真的没有开gzip，可是……这个 br 又是什么呢：

vislib.best 静态资源的 response headers 截图

那么就查一下吧：

MDN上提到了 content-encoding 的五个值，分别是 gzip、compress、deflate、identity、br。

• 其中gzip是最经常使用的，咱们都知道，也是 unix 中 gzip 支持的格式，这个格式是采用的deflate算法。
• compress 是来源于unix的compress程序，可是这个程序已经从大多数的UNIX发行版消失了，不少浏览器也再也不支持这一content-encoding 格式了，缘由是当年compress的做者为这个算法申请了专利，使用这个算法须要付版权费，因此这个算法逐渐被gzip 或者 deflate替代，而现在虽然当初的专利已经失效，可是gzip已经占据了主导地位了。
• deflate 则是基于deflate算法的压缩，这种算法也是咱们平常常见的zip压缩包和png图片格式采用的压缩算法。那既然deflate和gzip采用的压缩是同样的，那它与gzip到底有什么区别呢？其实就压缩算法来讲，这两者并无区别，主要的区别在于两者的校验和算法和数据格式不同。
• identity 则是表示内容没有通过压缩，也是content-encoding没有设置时候的默认值。
• 那br是啥呢？MDN解释说这是一种使用了Brotli算法的格式，Brotli算法是一种专为http content-encoding设计的压缩算法，是2013-2016年间由谷歌的工程师发明、实现的，br这种格式大约在2016-2017年间被各大主流浏览器和服务器支持。

除了MDN上提到的这五种格式外，还有另外几种官方或者非官方的格式，这里就不一一介绍了，有兴趣的能够去看下维基上的词条。

接下来就来对比下这几种压缩格式吧，

首先是为何gzip比deflate的使用更普遍呢？这两者的压缩算法同样的呀，并且其实deflate的速度要比gzip更快一些的。根据StackOverflow上的一个说法，这是由于不少浏览器多年以来都错误地实现了deflate算法(纳尼？？？具体是什么错误能够看本文的推荐阅读)，致使这一算法的实现逻辑很复杂，在不少浏览器版本上常常出问题，因此deflate的格式也属于不被推荐使用的一种。

那既然gzip和deflate实际上用的是同一种压缩算法，因此接下来就是gzip和br的对比。

具体实验我就不作了，贴一下别人的数据吧：

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

能够看出来br的表现要明显优于gzip。固然这里只是压缩率，可是咱们知道衡量一种压缩算法的性能压缩率只是一方面，压缩速度也很重要，毕竟咱们提升压缩率的目的就是为了减小数据传输的时间，若是传输时间省下来了，却在压缩上多花了时间，那就没什么意义了。

固然这方面也已经有人作过实验了，具体实验数据贴在下面：

首先解释一下这个数据，第一列是压缩算法，括号中是压缩算法的level，其中brotli有11个level，gzip有9个level，对每一个算法而言，level越高压缩效果越好，可是压缩的速度也就相应越慢。第二列是压缩的比例，第三列是速度，第四列和第五列是压缩速度和大小与gzip默认level(level6)的差别。能够看得出来，经过设置brotli的压缩level，能够达到比gzip压缩速度更高、压缩比也更高的水平，其中brotli的level4是压缩比与速度最平衡的。

可是压缩速度对咱们来讲也并不是那么重要，为何呢，由于咱们的静态资源大多采用cdn的方式加载，所以通常来讲静态资源只须要压缩一次，而后咱们的cdn就会把压缩过的资源缓存起来，以后再分发资源的时候就不须要再次压缩了，因此更多时候cdn都会采用压缩效率最高的level去压缩。固然，若是是对不通过cdn的动态资源的压缩的话，那最高level就不是一个最好的选择，这时候选择level4的brotli算法更合适。

能够看得出来不管是静态资源仍是动态资源，brotli的压缩性能都要比gzip好很多，并且根据caniuse，brotli的兼容性也很不错，主流浏览器基本都支持：

并且即便有浏览器不支持这一格式，服务器也能够根据浏览器设置的accept-encoding来提供降级处理，分发gzip压缩的资源，因此能够放心大胆地在你的网站上开启brotli。

那既然如此，如何开启brotli呢？

若是你的静态资源是使用cdn加载的话，能够找到你的cdn提供商，查看是否支持，例如cloudflare 中能够在speed ⇒ Optimization 中找到开启brotli的选项。

若是要在NGINX中配置brotli的话，能够参考这篇文档。

关于brotli和gzip，网上也有很多颇有意思的讨论文章，这篇文章也是参考这些文章写的，因此贴在下面，有兴趣的能够点进去看看：

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…