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

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

(圖：TCP/IP數(shù)據(jù)包的封裝，圖片來自互聯(lián)網(wǎng))

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

在 TCP/IP 協(xié)議中，數(shù)據(jù)傳輸?shù)淖钚挝皇前簿褪钦f，如果用戶請求一個文件，無論這個文件有多小，服務(wù)器端至少需要發(fā)送一個數(shù)據(jù)包。這就帶來一個有趣的問題：如果我們的文件內(nèi)容非常小，加上頭信息之后還不足一個包的長度，是否還有必要啟用 Gzip 壓縮呢?

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

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

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

【編輯推薦】

1. 高性能web開發(fā)之網(wǎng)絡(luò)傳輸環(huán)節(jié)
2. 高性能網(wǎng)站建設(shè)的14個原則
3. 網(wǎng)站高性能的核心優(yōu)勢該如何打造
4. 高性能WEB開發(fā)之flush讓頁面分塊逐步呈現(xiàn)
5. 高性能WEB開發(fā)應(yīng)用指南