最近我們用 YSlow 做頁面的性能分析時，發現有一個 js 不知什么原因沒有被 Gzip 壓縮。于是我找到負責服務器配置的相關同學咨詢，這個過程中巧遇淘叔度，聽了他的解釋才知道這是他們有意為之。

我們知道，數據在網絡上是以包的形式傳輸的，在 TCP/IP 協議中，大塊的數據會被切分成小塊，然后每一塊會被加上一些頭信息，最后，這些頭信息加上原始數據的一個片斷組成一個 IP 數據報，即一個數據包。如下圖所示：

(圖：TCP/IP數據包的封裝，圖片來自互聯網)

對于以太網來說，一個最大傳輸單元(MTU)為 1500 字節，也即一個 IP 數據報最大不能超過 1500 字節，除去頭信息和，最終的數據信息的長度一般最多可以比 1400 字節略多一些。

在 TCP/IP 協議中，數據傳輸的最小單位是包，也就是說，如果用戶請求一個文件，無論這個文件有多小，服務器端至少需要發送一個數據包。這就帶來一個有趣的問題：如果我們的文件內容非常小，加上頭信息之后還不足一個包的長度，是否還有必要啟用 Gzip 壓縮呢?

比如我們之前發現的那個 js 文件，內容其實只有 944 字節，加上 HTTP 頭信息，也還是不足 1400 字節。對這么小的文件來說，無論是否啟用 Gzip 壓縮，總是需要一個數據包來傳送。也就是說，對這個文件而言，Gzip 壓縮與否，網絡傳送的速度是一樣的，同時，如果對它啟用壓縮，反而需要多耗費一些服務器壓縮以及客戶端解壓的時間。

因此，對這樣的小文件來說，不用 Gzip 可能頁面性能更好，盡管這會讓 YSlow 的評分看起來低一些。考慮到 HTTP 頭的長度，禁用 Gzip 壓縮的文件一般應該在 1024 字節以內。當然，從另一個角度來說，大部分情況下，這樣的小 js 不應該存在，而是應該合并到某個更大的 js 中。不過，如果真的有某些特殊的無法合并的小文件，還是可以考慮一下這種禁用小文件 Gzip 的可能性的。

原文：http://oldj.net/article/a-gzipping-exception/

【編輯推薦】

1. 高性能web開發之網絡傳輸環節
2. 高性能網站建設的14個原則
3. 網站高性能的核心優勢該如何打造
4. 高性能WEB開發之flush讓頁面分塊逐步呈現
5. 高性能WEB開發應用指南