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…