关于css通配符性能问题不完全测试

关于css通配符这东西,一直以来的经验告诉我们,它的性能是极差的,对于不懂底层的人来说,貌似我们也觉得这个结论是可以接受的,虽然不知道这个结论是从哪里来的,之前小飞的博客中(CSS通用元素选择器的都市流言)有提到这点,在我看来css性能这种东西根本是感觉不出来的,所以也没太在意,当然我还是喜欢叛逆的反常规的想法,今天又看到艾文王微博上推了这篇文章,于是就想干脆简单测试下,由于是黑盒测试,条件简陋,所以结果仅作参考。

一、测试环境

操作系统: Win7 ultimate 32bit
浏览器版本: Google Chrome 16.0.912.63 m
测试工具: 浏览器自带开发人员工具
测试目的: 为了求证css通配符选择器性能是否真的很低
测试方法: 用大家所熟悉并认同的yui css reset做参考,对比性能。

二、测试过程

1,我直接把yui的reset demo页面和reset样式下载到本地做测试排除一些网络因素影响;页面地址:http://yuilibrary.com/yui/docs/cssreset/cssreset-context-example.html

2,使用Chrome打开本地页面,打开Chrome开发人员工具的timeline面板将loading和scripting记录勾勾去掉,留下一个rendering记录,也就是我们只记录页面的渲染,当页面只有html结构和样式的时候,我们可以认为这个渲染记录约等于css的渲染记录。

3,点击record后,刷新demo页面,得到yui reset css渲染timeline数据,右键保存数据为yui-20120103T131135.json;

4,同一个文件将yui里的css定义全部整合到通配符选择器中,并重复上一步操作,保存数据为uniselector-20120103T131500.json。

5,对比两个json数据中的渲染时间

yui-20120103T131135.json

uniselector-20120103T131500.json

6,在Chrome控制台,分别把两个数据的paint时间戳减去渲染开始时间戳得到渲染时间对比如下:

yui-20120103T131135.json

uniselector-20120103T131500.json

7,总结

经过多次测试,上面图中这两个数据差距还算是最小的,多的时候有几十毫秒,且都是*时间较少,从对比数据中我们可以看出,yui reset是对不同标签分别做reset,而通配符选择器是对所有标签做了yui reset中所有样式的reset,即使做了比yui reset更多样式重置,但是渲染时间依然还是比yui reset少,因此说通配符选择器性能更低的说法还有待进一步考量,毕竟测试条件有限,但是能说明一点问题;我承认*匹配的元素比直接罗列标签的写法匹配更多的元素,性能是会受到影响,但是数据的差异我觉得跟选择器的书写方式与数量有关,样式的继承与覆盖,过多的选择器导致浏览器计算样式次数增加等等也是影响结果的一个因素,不管是哪种reset方式,渲染时间相差50ms以下,可以说完全是感觉不到差别的,是否要为这一点差异付出更多的代价来优化,各自权衡吧。此文乃蛋疼文,测试不为别的,为了只是求真和反经验主义,至少在Chrome下结果是如此,由于web应用的不确定性,我们很难保证这个结果在某个情况下符合这样的结论,因此对于测试的结果还需辩证的看待,期待更多的讨论。顺便求其他浏览器的测试方法。

如需转载,请注明出处:https://i.wanz.im/2012/01/03/performance_testing_about_css_universal_selector/

Comments

  1. By 木匠

    回复

  2. By xinzhao5566

    回复

    • By 丸子

      回复

  3. By 真的是真的吗

    回复

    • By 丸子

      回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Time limit is exhausted. Please reload CAPTCHA.