html寫法對gzip壓縮率的影響
- 2019 年 12 月 4 日
- 筆記
前幾天在群里看到小杜分享一篇文章，《html寫法對gzip壓縮率的影響》，為此我也對這點分析了一下。 不知道大家有沒有看過這文章，作者是來自微博懶懶交流會，其內容我這裡先簡述一下。
Gzip演算法主要由哈費曼和LZ77演算法組成。 如果文件中有兩塊內容相同的話，那麼只要知道前一塊內容的位置和大小，通過特定的壓縮標識符， 我們就可以確定後一塊的內容。所以我們可以用位置長度這樣一對資訊，來替換後一塊內容。
舉例
<html> <head> <title></title> <meta charset="utf-8" /> </head> <body> <form action=""> <input class="J_Textarea" type="text" name="name123" id="id1"/> <input class="J_Textarea" type="password" name="name223" id="id2"/> <input class="J_Textarea" type="radio" name="name323" id="id3"/> <input class="J_Textarea" type="checkbox" name="name423" id="id4"/> </form> </body> </html>
通過gzip壓縮後，在chrome的開發者工具看到的size是563B。
下面把input標籤的屬性順序打亂後：
<html> <head> <title></title> <meta charset="utf-8" /> </head> <body> <form action=""> <input class="J_Textarea" type="text" name="name123" id="id1"/> <input name="name123" class="J_Textarea" type="password" id="id2"/> <input type="radio" id="id3" name="name323" class="J_Textarea"/> <input id="id4" type="checkbox" class="J_Textarea" name="name423"/> </form> </body> </html>
gzip壓縮，看到的size是578B。
文章內容大概如此，那麼，我果斷想了一下，CSS是不是也會有類似效果呢？ 先把CSS文件中的屬性都按順序寫：
@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;} .f2{font-size:14px; line-height: 26px; color:green;}
gzip看到的size是463B 屬性打亂順序後：
@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;} .f2{font-size:14px; color:green; line-height: 26px;}
gzip後的size是464B
由此得出結論，那麼不僅是html, 連CSS也有類似效果。 也許有人會問，行與行之間如果有其他class那結果會怎樣呢？
@charset "utf-8"; .f1{font-size:10px; line-height: 22px; color:red;} .f9{background: red;} .f2{font-size:14px; color:green; line-height: 26px;}
size:480B
這樣結果和上面的結論不一樣了。 可見，行與行之間的連續性對壓縮率也可能會產生影響。 換句話來說，程式碼相似率越大，壓縮率就越高。 不管是從壓縮率方面還是從程式碼整齊美觀方面來講，我們應該把程式碼按順序寫，方便了團隊，也方便了壓縮。
chrome開發者工具的network裡面size/content值不同之處：
除了研究這方面以外，我發現了chrome的開發者工具中的Network/Size欄有些難理解。 對他的Size和Content糾結了很久。不明白他們分別表示什麼意思。有時size比content值大，有時size比content值小。 經過CJ的指點和自己的實驗，得以下結果。
Size值是指網路傳輸內容的大小，這裡面包括了Request/Response headers 的gzip大小和 文件內容的gzip大小。 Content值是指主體內容body的gzip解壓後的大小, 也就是頁面文件的大小。
如果你看到Size比Content值大，說明他的headers也比body的gzip解壓後大得多了, 反之亦然。 可能你會發現，頁面第一次訪問得到的size值比刷新後的size值要少很多。那是因為頁面開啟了快取，自然就無需求再重新從網路載入一次。 個人感覺FireBug的值比Chrome的值要直觀，FireBug上面的大小是gzip的值。好像在chrome中沒發現有gzip的大小。 除非如果伺服器端有返回頭資訊中有Content-Length欄位，那麼也可以從這個欄位看到gzip的大小。但通常不會輸出這個欄位。
