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

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

1. 開啟gzip壓縮的好處是什麼?

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

  • 服務端傳送資料時可以配置 Content-Encoding:gzip,使用者說明資料的壓縮方式
  • 客戶端接受到資料後去檢查對應欄位的資訊,就可以根據相應的格式去解碼。
  • 客戶端請求時,可以用 Accept-Encoding:gzip,使用者說明接受哪些壓縮方法。

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

開啟gzip後

gzip後的大小從277KB到只有~91.2KB!

3. Nginxgzip設定

開啟/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

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

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

  • nginx作為反向代理的時候啟用,開啟或者關閉後端伺服器返回的結果,匹配的前提是後端伺服器必須要返回包含"Via"的 header頭。
  • 預設值: gzip_types text/html (預設不對js/css檔案進行壓縮)
  • 壓縮型別,匹配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_buffers 4 4k/8k
  • 設定系統獲取幾個單位的快取用於儲存gzip的壓縮結果資料流。 例如 4 4k 代表以4k為單位,按照原始資料大小以4k為單位的4倍申請記憶體。 4 8k 代表以8k為單位,按照原始資料大小以8k為單位的4倍申請記憶體。
  • 如果沒有設定,預設值是申請跟原始資料相同大小的記憶體空間去儲存gzip壓縮結果。

gzip_http_version:

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

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

$ sudo service nginx restart
複製程式碼

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

開啟gzip前

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

開啟gzip後

4. 如何驗證gzip

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

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

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

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

5. 雙端Gzip區別

不同之處在於:

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

免責宣告

不是打算教 WebpackNginx,只是覺得好玩就簡單寫了一下。

意思就是寫得略粗糙,別噴我。。。

求一份深圳的內推

好了,又水完一篇,入正題:

目前本人在(又)準備跳槽,希望各位大佬和HR小姐姐可以內推一份靠譜的深圳前端崗位!996.ICU 就算了。

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

  • 微信:huab119
  • 郵箱:454274033@qq.com

作者掘金文章總集

公眾號

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

相關文章