「簡明效能優化」雙端開啟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. 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：

  • 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作為二重保障就會高效很多。
  • 注：具體是在請求時實時壓縮，或在構建時去生成壓縮檔案，就要看專案業務情況。

免責宣告

不是打算教 Webpack或Nginx，只是覺得好玩就簡單寫了一下。

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

求一份深圳的內推

好了，又水完一篇，入正題：

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

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

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

作者掘金文章總集

公眾號

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

相關文章