算法 – 用于压缩的HTML属性的优化顺序

概述我读到某处按照一定顺序组织 HTML属性可以提高 HTML文档的压缩率. (我想我从Google或雅虎推荐更快的网站阅读这篇文章).如果我回想起来,建议首先放置最常见的属性(例如,id等),然后按其字母顺序排列. 我有点困惑了例如,如果id属性放在每个p标签之后,该id将包含唯一的值.因此,重复的字符串将被限制为：< p id =“(例如,< p id =”1“>和< p id =”2“/>)因为 我读到某处按照一定顺序组织 HTML属性可以提高 HTML文档的压缩率. (我想我从Google或雅虎推荐更快的网站阅读这篇文章).如果我回想起来,建议首先放置最常见的属性(例如,ID等),然后按其字母顺序排列.

我有点困惑了例如,如果ID属性放在每个p标签之后,该ID将包含唯一的值.因此,重复的字符串将被限制为：< p ID =“(例如,< p ID =”1“>和< p ID =”2“/>)因为ID需要独一无二,我看到这是实际上对压缩造成不利影响.

我错了吗？

如果我需要通过一个带有随机排序属性的静态网页,我应该使用什么逻辑来组织属性来实现最大的压缩？

注意：我在说Gzip压缩(如果重要)：http://www.gzip.org/algorithm.txt

解决方法 你的目标是鼓励反复的内容.所以< p class =“foo”ID =“a”> bar< / p> …< p class =“foo”ID =“b”> bof< / p>可能比< p ID =“a”class =“foo”> bar< / p> …< p ID =“b”class =“foo”> bof< / p>,并且两者通常比

bar< / p> …< p ID =“b”class =“foo”> bof< / p> ;.

但真的,区别是微不足道的.你最好只是以最可读的方式为自己的利益编写你的标记,并让mod_deflate继续工作.通过这种微型优化,您将不得不长期保存单个TCP数据包,并且在微观级别上再次猜测压缩器通常会产生意想不到的可能的负面结果.

对于某些元素,可读性也可能意味着首先将“共同”属性设置,例如< input type>通常是第一个列出的属性;通常你会计算出你自己的属性顺序样式,如果它是一致的,我想这将节省你几个字节在这里和那里.我不会选择原始的字母顺序作为一致的顺序.所有这一切都是规范的XML将会产生的.

即使是Google.com的头版,因为致力于以可读性,基本验证和各种良好做法为代价来削减字节,所以臭名昭着,不用为属性使用一致的顺序.

总结

以上是内存溢出为你收集整理的算法 – 用于压缩的HTML属性的优化顺序全部内容，希望文章能够帮你解决算法 – 用于压缩的HTML属性的优化顺序所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。