你知道Chrome Network ，Size 和 Content 為什麼有兩行引數嗎？
摘要：
Hello，騷年們，當大家歡脫的 Debug 介面的時候，有沒有在意過 Chrome Network 裡 Size 和 Time 兩項是兩行呢？如下圖箭頭所示：
借這篇文章我們來分析一下它的含義，我們聚焦
/api/v1/myaddress/all
這個介面
...
Hello，騷年們，當大家歡脫的 Debug 介面的時候，有沒有在意過 Chrome Network 裡 Size 和 Time 兩項是兩行呢？如下圖箭頭所示：
/api/v1/myaddress/all
這個介面
Size 有兩行：
- 第一行表示的是資料的 傳輸時 的大小，例如上圖中的
44.3KB， - 第二行表示的是資料 實際 的大小
441KB
解釋：
因為這個介面返回資料量比較大，所以後端採取了 gzip 壓縮，從響應頭的 Content-Encoding 我們也能看出
gzip 壓縮演算法將將原有
441KB 壓縮至
44.3KB ,傳輸大小縮短
10倍
，大大的提高了介面傳輸的效率。
需要注意的點：
gzip 壓縮只會壓縮 響應體 內容， 所以適用於返回資料量大的時候，如果資料量太小的話，有可能會導致資料 傳輸時 的大小比 實際 大小要大( 例如加入一些額外的響應頭 )
一般例如 SpringMVC 等Web框架可以指定資料大小到多少時使用 Gzip
接下來我們來看另外一列 Timing ：
558ms 118ms
下圖是這些時間含義的解釋
解釋：
第一行的時間就代表了上圖列的所有專案：例如 解析dns ， 建立連線 ， 等待伺服器返回資料 ， 傳輸資料 等
第二行的時間是 總時間 - 資料傳輸 的時間
總結時間：
從上面的分析中我們看到 從 客戶端請求到伺服器處理結束準備返回資料 花了 118ms （ 算蠻久了 ），但是在進行 傳輸資料 的時候花費了 480ms
每個使用者網路頻寬不一樣，對於網慢的使用者來說，這個體驗可能更差，所以在編寫程式碼的時候，返回的資料量要儘量精簡。
個人覺得理解 Chrome Network 的引數有助於我們對介面的效能有一個比較直觀的感覺~