前端生產環境中將js、css、圖片等文件進行壓縮的好處顯而易見,經過減小數據傳輸量減少傳輸時間,節省服務器網絡帶寬,提升前端性能。css
一、瀏覽器請求數據時,經過Accept-Encoding說明本身能夠接受的壓縮方法html
二、服務端接收到請求後,選取Accept-Encoding中的一種對響應數據進行壓縮前端
三、服務端返回響應數據時,在Content-Encoding字段中說明數據的壓縮方式webpack
四、瀏覽器接收到響應數據後根據Content-Encoding對結果進行解壓nginx
注:若是服務器沒有對響應數據進行壓縮,則不返回Content-Encoding,瀏覽器也不進行解壓web
nginx中有關gzip的配置項以下:npm
一、gzip on|off:默認off後端
開啓或者關閉gzip模塊瀏覽器
二、gzip_comp_level 4:默認1,建議選擇爲4服務器
gzip壓縮比/壓縮級別,壓縮級別 1-9,級別越高壓縮率越大,壓縮時間越長,消耗CPU也越大。
三、gzip_min_length 1k:默認0,無論頁面多大都壓縮
設置容許壓縮的頁面最小字節數,頁面字節數從header頭中的Content-Length中進行獲取。
建議設置成大於1k的字節數,小於1k可能會越壓越大。 即: gzip_min_length 1024
四、gzip_static on|off:默認off
gzip_static是nginx對於靜態文件的處理模塊,能夠讀取預先壓縮的gz文件,多與構建時壓縮同時使用,詳見下節構建時壓縮介紹
五、更多配置信息參考:Nginx的gzip
webpack的compression-webpack-plugin插件用於支持構建項目時壓縮文件,Vue項目爲例,具體配置以下:
一、首先安裝插件,命令:npm install --save-dev compression-webpack-plugin
二、在config/index.js文件中打開Gzip開關,配置須要壓縮的文件擴展名
三、webpack.prod.conf.js中設置具體壓縮配置項
四、打包後會同時保留原文件和壓縮後的文件,存儲等條件容許的狀況下,原文件也建議發佈到服務器以支持不兼容gzip的瀏覽器
五、服務端nginx啓動gzip_static
gzip_static是nginx對於靜態文件的處理模塊,該模塊能夠讀取預先壓縮的gz文件,這樣能夠減小每次請求進行gzip壓縮的CPU資源消耗。該模塊啓用後,nginx首先檢查是否存在請求靜態文件的gz結尾的文件,若是有則直接返回該gz文件內容。
爲了要兼容不支持gzip的瀏覽器,啓用gzip_static模塊就必須同時保留原始靜態文件和gz文件。這樣的話,在有大量靜態文件的狀況下,將會大大增長磁盤空間。咱們能夠利用nginx的反向代理功能實現只保留gz文件(參考文章中提到本文何嘗試)。
nginx須要安裝http_gzip_static_module以支持gzip_static,具體方法見《源碼安裝nginx》
6、生產環境:proxy_pass+gzip
上線後發現生產環境中靜態文件的壓縮配置沒有起做用,通過定位發現生產環境加了反向代理致使nginx沒有返回.gz文件。看到參考文章中2、三兩篇時肯定是gzip_http_version和proxy_set_header Accept-Encoding配置問題。
若是咱們使用了proxy_pass進行反向代理,那麼nginx和upstream server之間默認是用HTTP/1.0協議通訊的。
若是咱們的Cache Server也是nginx,而前端的nginx沒有開啓gzip。 同時,咱們後端的nginx上沒有設置gzip_http_version爲1.0,那麼Cache的url將不會進行gzip壓縮。
因此,最終的解決方案是,在靜態文件服務nginx中配置gzip_http_version爲1.0
同時,反向代理服務器應該添加請求頭proxy_set_header Accept-Encoding ‘gzip’,通知靜態文件服務器客戶端可以理解的gzip壓縮文件,使其返回.gz文件
Nginx開啓Gzip詳解(gzip_http_version部分):https://blog.csdn.net/zhuyiquan/article/details/52709864
nginx反向代理和gzip_static模塊使用:https://yq.aliyun.com/ziliao/46446