css的效率和浏览器渲染的速度

2016-02-20 00:25 7 1 收藏

今天图老师小编给大家介绍下css的效率和浏览器渲染的速度,平时喜欢css的效率和浏览器渲染的速度的朋友赶紧收藏起来吧!记得点赞哦~

【 tulaoshi.com - Web开发 】

浏览器如何读取你的CSS选择器有一个很重要的原则,那就是它们从右到左读取。这意味这像 ul > li a[title="home"] 这样的选择器,a[title="home"] 将是最先被读取的。

我承认我并不经常想这个问题......我们写的css的效率是怎么样的呢,浏览器渲染的速度又如何呢?

这是应该是浏览器开发者应该关心的(页面加载更快,用户就会更愉快)。Mozilla有一篇文章: about best practices . Google 当然也很关心这个问题,他们也有这样一篇文章:Optimize browser rendering 。

让我们了解下他们主要倡导的东东,然后讨论他们的实用性。

从右到左

浏览器如何读取你的CSS选择器有一个很重要的原则,那就是它们从右到左读取。这意味这像 ul > li a[title="home"] 这样的选择器,a[title="home"] 将是最先被读取的。这一部分通常被称为 key selector (可否称为目标选择器 -_-!)选择器的最后一部分,也是被选择的标签。

ID's 是最有效率的,通用符是最慢的

有四种目标选择器:ID, class, tag和通用符。看下他们各自的效率如何:
#main-navigation { } /* ID (最快) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Class */
ul li a.current { } /* Class *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universal (最慢) */
#content [title='home'] /* Universal */ 然后我们结合从右到左和目标选择器的概念,我们可以知道下面这个选择器并不高效:
#main-nav > li { } /* 看着很快实则很慢 */
尽管这让人有点费解......因为ID's是最高效的,浏览器可以通过ID迅速的找到 li。但事实是,li 标签是被先读取的。

不要用标签修饰

死也不要像下面这样干:

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

 

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

 

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

ID's 是唯一的,所以不需要用标签修饰,这只会让它更低效。
如果你可以避免的话,也不要用它修饰 class 。class 不是唯一的,所以理论上你可以把它用在不同的标签。如果你愿意的话,你可以用标签控制不同的样式,这样你可能需要标签修饰(比如:li.first),但这样做的人很少,所以,don't .

绝对没有比用后代选择器更糟糕的做法了
David Hyatt:
后代选择器是CSS里最昂贵的选择器,昂贵得可怕特别是当它放在标签和通用符后面时。
就如下面这个东东一样,绝对的效率毒瘤:

 

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

 

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

一个选择器渲染失败比这个选择器被渲染更高效

我不是很确定是否有更好的证据去证明这一点,因为如果你有大量的选择器在CSS样式表里无法找到,这样的事情貌似很离奇,但一点必需注意的是,从右到左的解释一个选择器来说,一旦它找不到,那它就会停止尝试。然而如果它找到了,那它就需要花更多精力去解释了。

试想一下为何你这样写选择器

思考下这东东:

 

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

 

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

你可能不需要从 a 选择器开始(如果你只是想换个字体)。下面这个可能更高效些:

 

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

 

(本文来源于图老师网站,更多请访问http://www.tulaoshi.com/webkaifa/)

实用性

还刻前面提到的Mozilla的一篇文章?已经有十年了。事实是:计算机比十年前变慢了(不是我理解错了,还是作者想说现在的WEB越来越复杂了)。我感觉这东东在当年似乎还更受重视。十年前我还是个21岁的英俊小生,当然我不觉得那里我会认识css这东东。所以我也无法跟你讲以前的情况......但我觉得渲染效率的问题之所以没被重视是因为这从来就不是一个大问题。
这是我的一些看法:不管怎样上面提到的东东都是有意义的,你可以按照上面的方法去做,因为它并不会限制你的CSS制作。但你也没必要太教条主义。如果你是个完美主义者,而之前又没有考虑过那东东,那是时候去重新看一下你之前写的一些样式是否有改进的地方了。如果你没发现你的网站明显的渲染缓慢,那大可别太在意,在以后的工作中多注意就行了。

超级快速,零实用性

我们知道ID's 是最高效的选择器。当你想让渲染速度最高效时,你可能会给每个独立的标签配置一个ID,然后用这些ID写样式。那会超级快,也超级荒唐。这样的结果是语义极差,维护难到了极点。即使在核心部分你也不应该见过这样做的。我认为这个可以提醒我们不要为了高效的CSS放弃语义和可维护性。

Thanks to Jason Beaudoin for emailing me about the idea. If anyone knows more about this stuff, or if you have additional tips that you use in this same vein, let’s hear it!

顺便提一下,因为CSS选择器被很多javascript库使用,上面提到的东东仍然适用,ID选择器还是最快的,后代选择器和类似的东东比较慢。

PS:看谁还敢用N多的后代选择器。。。还有反对我用ID的。。。哇哈哈。。。

来源:http://www.tulaoshi.com/n/20160220/1631830.html

延伸阅读
说到web性能,前端工程师很自然地反应是yahoo的30+条优化规则。这些规则可以将网页加载从原来的几秒甚至十几秒较少到3s甚至1s以内。当一个完整界面展现在用户眼前时,内容就通过不同的字体、图片以及多媒体传达给用户。使用户在1s内看到网页和使用户留在网页上几分钟甚至几十分钟同样重要。字体作为内容承载信息的重要部分,若使用不适当的字体...
标签: Web开发
我很久以前就开始计划着整理一下CSS选择器的浏览器支持,因为CSS3增加了很多非常有用的选择器。之前我也写过一篇《使用CSS选择器创建个性化链接样式 》,作为对CSS选择器的初步研究。 kimblim网站整理了一份很全面的CSS选择器支持情况,我将其翻译过来并进行进一步的整理,将其尽可能的简化。同时结合evotech网站整理的CSS选择器支持列表,以...
标签: Web开发
从“译言”上的一篇文章据悉各浏览器 Javascript 的对比。我个人作为一名“准”的 Javascript 开发者,对此事自然比较的关注。SunSpider 的测试面我还是保持对其信任的态度的,正如原文所说的“它是一组被精心设计的测试,易于运行也非常全面”。 下面是测试的内容: 3d - 纯粹 JavaScript 的...
标签: Web开发
区别IE6与FF:        background:orange;*background:blue; 区别IE6与IE7:        background:green !important;background:blue; 区别IE7与FF:        background:orange; *background:green; 区别FF,IE7,IE6:    &n...
标签: Web开发
1、十六进制的颜色值对位数与大小写 编写十六进制颜色值时你可能会用小写字母或省略成3位数,关于这写法没找到确实的数据证明对浏览器的渲染效率是否有影响,但十六进制的颜色值默认标准是大写及6位数标注。在未知情况下不希望冒险而降低了渲染的效率。 * 不赞成 - color:#f3a; * 建议用 - color:#FF33AA; 2、display与visibility的差异 他...

经验教程

77

收藏

21
微博分享 QQ分享 QQ空间 手机页面 收藏网站 回到头部