gzip壓縮初探

前言

咱們平時工做中傳文件時爲了提升傳輸速度通常都會把文件壓縮一下再傳，那樣速度回快一些，尤爲是那些文件不少的文件夾，比較經常使用的壓縮格式就是zip,rar了。那咱們平常網頁中利用http協議請求的那些資源可不能夠壓縮呢，固然是能夠了，這就要說到咱們今天的主角gzip了。

gzip以前我並無在項目中用過，就往往查閱文檔時據說某一個框架文件經gzip壓縮以後就變得多小多小了，甚是好奇，因此今天特地查了一下。

gzip壓縮的好處

好處固然是很明顯的啦，就是能夠大大減少傳輸文件的大小，提升頁面加載速度、節省帶寬。並且壓縮的比率是能夠調節的，咱們經常使用的服務器端壓縮是3到10倍，一個原本100k的文件能壓縮到20k左右，想一想都美滋滋，今天看了咱們公司的官網用了gzip才發現壓縮與不壓縮差異仍是蠻大的，哈哈。固然並非全部的文件都能壓縮這麼多，像咱們經常使用的CSS,JS文件是能夠壓縮不少的，而圖片那些文件原本就壓縮過了就沒有多少能夠壓縮了。

gzip壓縮的過程

gzip是一種流行的文件壓縮算法，他會把文件壓縮爲.gz而後傳給瀏覽器，最後瀏覽器負責解壓文件呈現給客戶。因此，要想實現文件的gzip壓縮與解壓，服務端和瀏覽器端都得支持。他們的通訊過程大致以下：

• 首先咱們要將http請求的請求頭中的==accept-encoding==屬性設爲gzip、deflate，代表瀏覽器支持gzip壓縮方式
• web服務器收到瀏覽器的請求以後，會判斷瀏覽器是否支持gzip壓縮，若是支持就傳輸壓縮後的響應內容，若是不支持就傳輸未壓縮的內容。固然，服務器會對壓縮文件進行緩存，並非每次請求都要再壓縮一次
• 瀏覽器接收到內容後判斷文件是否被壓縮，若是壓縮了就先解壓再解析（IE5.5以上才支持gzip）

誰來壓縮

答案就兩個，不是服務端就是客戶端。

上面已經講到了之前經常使用的一種方式是服務端壓縮，瀏覽器解壓。其實咱們開發端但是能夠壓縮的，好比咱們平常用的打包軟件webpack就有compression-webpack-plugin這麼個插件專門作壓縮的，大概用法以下：

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

plugins: [
 new CompressionPlugin({
    test: /\.js/,  //知足正則表達式的會被壓縮
    filename: '[path].gz[query]',  //目標文件名
    algorithm: 'gzip',  //使用gzip壓縮
    threshold: 10240,  //資源文件大於10240b=10k時會被壓縮
  })
]

既然已經存在了服務端響應請求時壓縮，爲何還會存在應用構建時壓縮這種方式呢？
存在而且被不少人使用就必定有它存在的價值，帶着這份疑問我查詢資料得知：gzip壓縮文件是分等級的，共十級。等級越高壓縮效果越好可也覺得着更耗時嘛。若是你在服務端相應請求時壓縮，那我請求一個文件不仍是得等很久？並且即使是有了緩存，服務端壓縮時仍是有時間開銷的。

可是構建時壓縮就不存在上面這些問題了，咱們如今的不少項目都是spa的項目，即便不是也是須要構建工具打包什麼的，那咱們在這個過程當中就最大限度地使用gzip壓縮代碼，讓服務器直接使用不是很好嗎，反正咱們也不會每天打包生產版本的，哈哈。

固然，這樣服務端也得相應地更改配置來讀取咱們的壓縮文件，會要麻煩一些，因此最終使用哪一種壓縮方式還得根據具備的啞無需求來，可是使用gzip壓縮是頗有必要的，畢竟效果是擺在那裏的。

總結

在以前的一個vue單頁面應用中我就遇到過打包以後文件仍是太大的問題，當時通過各類分拆和異步組件以後首屏文件仍是有一點大，我當時也想到了gzip，可當時的後臺忽悠我說很麻煩，可我今天查了一下服務端壓縮的話他們也不要加多少配置。因此啊，做爲一個前端攻城獅服務端的知識多瞭解一下仍是有必要的，能夠防忽悠嘛，哈哈...

今天用uglifyjs-webpack-plugin這個插件配置代碼壓縮信息時纔想起咱們這個項目貌似木有使用gzip，因而乎從頭瞭解了一下，因此記錄一下。之後要多多利用起來！

參考

• 探索HTTP傳輸中gzip壓縮的祕密
• HTTP方式下的Gzip壓縮傳輸
• webpack4 的生產環境優化
• compression-webpack-plugin插件文檔