「簡明效能優化」雙端開啟Gzip指南

前端勸退師發表於2019-04-18

優化

本文目錄：

1. 開啟gzip壓縮的好處

可以減小檔案體積，傳輸速度更快。gzip是節省頻寬和加快站點速度的有效方法。

服務端傳送資料時可以配置 Content-Encoding：gzip，使用者說明資料的壓縮方式

客戶端接受到資料後去檢查對應欄位的資訊，就可以根據相應的格式去解碼。

客戶端請求時，可以用 Accept-Encoding:gzip，使用者說明接受哪些壓縮方法。

在 http／1.0協議中關於服務端傳送的資料可以配置一個 Content-Encoding 欄位，這個欄位用於說明資料的壓縮方法

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
複製程式碼

客戶端在接受到返回的資料後去檢查對應欄位的資訊，然後根據對應的格式去做相應的解碼。客戶端在請求時，可以用 Accept-Encoding欄位說明自己接受哪些壓縮方法。

Accept-Encoding: gzip, deflate
複製程式碼

2. `Webpack`的 `gzip`設定

這裡使用的外掛為：CompressionWebpackPlugin

const CompressionWebpackPlugin = require（'compression-webpack-plugin'）
module.exports = { 
    “plugins”：[new CompressionWebpackPlugin] 
}
複製程式碼

具體配置：

const CompressionWebpackPlugin = require('compression-webpack-plugin');

webpackConfig.plugins.push(
    new CompressionWebpackPlugin({
      asset: '[path].gz[query]',
      algorithm: 'gzip',
      test: new RegExp('\\.(js|css)$'),
      // 只處理大於xx位元組 的檔案，預設：0
      threshold: 10240,
      // 示例：一個1024b大小的檔案，壓縮後大小為768b，minRatio : 0.75
      minRatio: 0.8 // 預設: 0.8
      // 是否刪除原始檔，預設: false
      deleteOriginalAssets: false
    })
)
複製程式碼

開啟gzip前

開啟gzip後gzip後的大小從277KB到只有~91.2KB！

3. `Nginx`的 `gzip`設定

開啟 /etc/nginx/conf.d編寫以下配置。

server {
    gzip on;
    gzip_static on;    
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_proxied  any;
    gzip_vary on;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    # 注：99.99%的瀏覽器基本上都支援gzip解壓了，所以可以不用設這個值,保持系統預設即可。
    gzip_http_version 1.1;    
    ...
}
複製程式碼

gzip on|off：

預設值: gzip off
開啟或者關閉gzip模組

gzip_static on|off：

預設值: gzip_static off
nginx對於靜態檔案的處理模組
該模組可以讀取預先壓縮的gz檔案，這樣可以減少每次請求進行gzip壓縮的CPU資源消耗。
該模組啟用後， nginx首先檢查是否存在請求靜態檔案的gz結尾的檔案，如果有則直接返回該gz檔案內容。
為了要相容不支援gzip的瀏覽器，啟用 gzip_static模組就必須同時保留原始靜態檔案和gz檔案。這樣的話，在有大量靜態檔案的情況下，將會大大增加磁碟空間。我們可以利用nginx的反向代理功能實現只保留gz檔案。

gzip_types mime-type[mime-type...]:

預設值: gzip_types text/html (預設不對js/css檔案進行壓縮)
nginx作為反向代理的時候啟用，開啟或者關閉後端伺服器返回的結果，匹配的前提是後端伺服器必須要返回包含"Via"的 header頭。
壓縮型別，匹配MIME型別進行壓縮

gzip_proxied[off|expired|no-cache|no-store]...:

off - 關閉所有的代理結果資料的壓縮
no-cache - 啟用壓縮，如果header頭中包含"Cache-Control:no-cache" 頭資訊

gzip_vary on|off:

和 http頭有關係，加個 vary頭，給代理伺服器用的，有的瀏覽器支援壓縮，有的不支援，所以避免浪費不支援的也壓縮，所以根據客戶端的 HTTP頭來判斷，是否需要壓縮

gzip_comp_level:

預設值：1(建議選擇為4~6)
gzip壓縮比/壓縮級別，壓縮級別1-9，級別越高壓縮率越大，當然壓縮時間也就越長（傳輸快但比較消耗cpu）。

gzip_buffers:

預設值: gzip_buffers44k/8k
設定系統獲取幾個單位的快取用於儲存 gzip的壓縮結果資料流。
例如 4 4k 代表以4k為單位，按照原始資料大小以4k為單位的4倍申請記憶體。 4 8k 代表以8k為單位，按照原始資料大小以8k為單位的4倍申請記憶體。
如果沒有設定，預設值是申請跟原始資料相同大小的記憶體空間去儲存 gzip壓縮結果。

gzip_http_version:

預設值: gzip_http_version1.1(就是說對 HTTP/1.1協議的請求才會進行 gzip壓縮)
注：99.99%的瀏覽器基本上都支援 gzip解壓了，所以可以不用設這個值,保持系統預設即可。

儲存配置後，重新啟動 Nginx:

$ sudo service nginx restart
複製程式碼

開啟gzip前

開啟gzip後

4. 如何驗證 gzip？

可以看 Network，但這裡我更推薦用 curl:

通過使用 curl測試每個資源的請求響應，並檢查 Content-Encoding：

顯示 Content-Encoding:gzip，即為配置成功。

5. 雙端Gzip區別及其意義

不同之處在於：

Webpack壓縮會在構建執行期間一次壓縮檔案，然後將這些壓縮版本儲存到磁碟。
nginx在請求時壓縮檔案時，某些包可能內建了快取,因此效能損失只發生一次(或不經常),但通常不同之處在於,這將在響應 HTTP請求時發生。
對於實時壓縮,讓上游代理(例如 Nginx)處理 gzip和快取通常更高效，因為它們是專門為此而構建的,並且不會遭受服務端程式執行時的開銷(許多都是用C語言編寫的) 。
使用 Webpack的好處是， Nginx每次請求服務端都要壓縮很久才回返回資訊回來，不僅伺服器開銷會增大很多，請求方也會等的不耐煩。我們在 Webpack打包時就直接生成高壓縮等級的檔案，作為靜態資源放在伺服器上，這時將 Nginx作為二重保障就會高效很多。
注：具體是在請求時實時壓縮，或在構建時去生成壓縮檔案，就要看專案業務情況。