「簡明性能優化」雙端開啓Gzip指南

時間 2019-11-07

標籤簡明性能優化雙端開啓 gzip 指南欄目系統性能简体版

原文原文鏈接

本文目錄：

1. 開啓gzip壓縮的好處

能夠減少文件體積，傳輸速度更快。gzip是節省帶寬和加快站點速度的有效方法。javascript

服務端發送數據時能夠配置 Content-Encoding：gzip，用戶說明數據的壓縮方式css

客戶端接受到數據後去檢查對應字段的信息，就能夠根據相應的格式去解碼。html

客戶端請求時，能夠用 Accept-Encoding:gzip，用戶說明接受哪些壓縮方法。前端

在 http／1.0協議中關於服務端發送的數據能夠配置一個 Content-Encoding 字段，這個字段用於說明數據的壓縮方法vue

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
複製代碼

客戶端在接受到返回的數據後去檢查對應字段的信息，而後根據對應的格式去作相應的解碼。客戶端在請求時，能夠用 Accept-Encoding字段說明本身接受哪些壓縮方法。java

Accept-Encoding: gzip, deflate
複製代碼

2. `Webpack`的 `gzip`設置

這裏使用的插件爲：CompressionWebpackPluginwebpack

const CompressionWebpackPlugin = require（'compression-webpack-plugin'）
module.exports = { 
    「plugins」：[new CompressionWebpackPlugin] 
}
複製代碼

具體配置：nginx

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編寫如下配置。web

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做爲二重保障就會高效不少。
注：具體是在請求時實時壓縮，或在構建時去生成壓縮文件，就要看項目業務狀況。