html写法对gzip压缩率的影响
前几天在群里看到小杜分享一篇文章,《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; color:red; line-height: 22px;} .f9{background: red;} .f2{font-size:14px; color:green; line-height: 26px;}
size:482B
@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的大小。但通常不会输出这个字段。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 智能桌面机器人:用.NET IoT库控制舵机并多方法播放表情
· Linux glibc自带哈希表的用例及性能测试
· 深入理解 Mybatis 分库分表执行原理
· 如何打造一个高并发系统?
· .NET Core GC压缩(compact_phase)底层原理浅谈
· 手把手教你在本地部署DeepSeek R1,搭建web-ui ,建议收藏!
· 新年开篇:在本地部署DeepSeek大模型实现联网增强的AI应用
· Janus Pro:DeepSeek 开源革新,多模态 AI 的未来
· 互联网不景气了那就玩玩嵌入式吧,用纯.NET开发并制作一个智能桌面机器人(三):用.NET IoT库
· 【非技术】说说2024年我都干了些啥