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

浏览器如何读取你的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 标签是被先读取的。

不要用标签修饰

死也不要像下面这样干:

ul#main-navigation { }

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

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

html body ul li a { }

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

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

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

思考下这东东:

#main-navigation li a { font-family: Georgia, Serif; }

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

#main-navigation { font-family: Georgia, Serif; }

实用性

还刻前面提到的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的。。。哇哈哈。。。

时间: 2024-08-03 07:58:06

css的效率和浏览器渲染的速度的相关文章

关于提高浏览器渲染页面速度的建议

怎样尽可能的缩短浏览器上页面渲染的时间,文章从以下几方面着手: 写出高效的css代码 避免使用css表达式 把css文件放在页面顶部 指定页面图片的尺寸 页面头部标明文档编码 一,写出高效的css代码 首先弄清浏览器解析html代码的过程:构建一个dom树,页面要显示的各元素都会创建到这个dom树当中.每当一个新元素加入到这个dom树当 中,浏览器便会通过css引擎查遍css样式表,找到符合该元素的样式规则应用到这个元素上.css引擎查找样式表,对每条规则都按从右到左的顺序去匹 配. 了解过程后

网站大提速 之一 浏览器渲染速度优化

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 前言: 要实现网站的大提速,必须在各个环节进行精确的设置和安排.网站一旦打开速度变慢,往常,站长们第一时间肯定会认为"服务器慢",其实看完本章后,你会发现或许结果并不完全是这样.影响网站速度的因素千差万别,服务器仅是其中一小部分因素而已.一种常见的情况,同样的服务器,网站与网站之间的打开速度也千差万别,这就和网站的制作工艺

优化浏览器渲染:避免CSS expressions

概述 CSS表达式会降低浏览器的渲染性能:用其他方案替换它们将会改善IE浏览器的渲染性能. 注意:本节最佳实践只适用于Internet Explorer 5到7,它们支持CSS表达式.Internet Explorer 8放弃使用CSS表达式,而其他浏览器是不支持的. 详细信息 作为一种动态改变文档属性来响应各种事件的的手段,Internet Explorer 5引入了CSS表达式或 "动态属性".它们由在CSS声明中的CSS属性值里嵌入JavaScript表达式构成.在大多数情况下,

浏览器渲染过程与性能优化

大家都知道万维网的应用层使用了 HTTP 协议,并且用浏览器作为入口访问网络上的资源.用户在使用浏览器访问一个网站时需要先通过 HTTP 协议向服务器发送请求,之后服务器返回 HTML 文件与响应信息.这时,浏览器会根据 HTML 文件来进行解析与渲染(该阶段还包括向服务器请求非内联的 CSS 文件与 JavaScript 文件或者其他资源),最终再将页面呈现在用户面前. 现在知道了网页的渲染都是由浏览器完成的,那么如果一个网站的页面加载速度太慢会导致用户体验不够友好,本文通过详解浏览器渲染页面

【Web动画】CSS3 3D 行星运转 && 浏览器渲染原理

承接上一篇:[CSS3进阶]酷炫的3D旋转透视 . 最近入坑 Web 动画,所以把自己的学习过程记录一下分享给大家. CSS3 3D 行星运转 demo 页面请戳:Demo.(建议使用Chrome打开) 本文完整的代码,以及更多的 CSS3 效果,在我 Github 上可以看到,也希望大家可以点个 star. 嗯,可能有些人打不开 demo 或者页面乱了,贴几张效果图:(图片有点大,耐心等待一会) CSS3 3D 行星运转效果图 随机再截屏了一张: 强烈建议你点进 Demo页感受一下 CSS3

提高编写CSS代码效率的10个习惯

  这篇文章介绍了提高编写CSS代码效率的10个习惯,看了觉得不错,大家可以学习一下.文章底部有原文链接. 1.保持一贯性. 就像其它的任何事一样,值得一直保持一贯性.保持连贯性,而不是想到什么就给id和class命名什么. CSS的级联样式有利于加深你的记忆,而且充分利用样式的继承去设置样式表. 首先声明通用的部分的样式,然后继续声明不通用的.这样当你需要的时候更容易的去覆盖一个特定的样式.因为样式更易于阅读和更具逻辑性,你会发现编写CSS更迅速. 使用一种最是适合你的方式. 复位和覆盖 链接

浏览器渲染流水线解析与网页动画性能优化

若干年前,我写过一篇介绍浏览器渲染流水线的文章 - How Rendering Work (in WebKit and Blink),这篇文章,一来部分内容已经过时,二来缺少一个全局视角来对流水线整体进行分析,所以打算重新写一篇新的文章,从一个更高抽象层次和高度简化的方式对浏览器的渲染流水线进行解析,能让大部分页端同学都能够看的明白,并以此作为指引来分析和优化页面的渲染/动画性能. 有些基本概念如图层,分块,光栅化基本没有发生变化,如果读者不理解的话请参考 How Rendering Work

浏览器渲染流水线解析(一)

若干年前,我写过一篇介绍浏览器渲染流水线的文章 - How Rendering Work (in WebKit and Blink),这篇文章,一来部分内容已经过时,二来缺少一个全局视角来对流水线整体进行分析,所以打算重新写一篇新的文章,从一个更高抽象层次和高度简化的方式对浏览器的渲染流水线进行解析,能让大部分页端同学都能够看的明白,并以此作为指引来分析和优化页面的渲染/动画性能. 有些基本概念如图层,分块,光栅化基本没有发生变化,如果读者不理解的话请参考 How Rendering Work

浏览器渲染流水线解析(二)

2. 网页动画 动画可以看做是一个连续的帧序列的组合.我们把网页的动画分成两大类 -- 一类是合成器动画,一类是非合成器动画(UC 内部也将其称为内核动画,虽然这不是 Chrome 官方的术语). 合成器动画顾名思义,动画的每一帧都是由 Layer Compositor 生成并输出的,合成器自身驱动着整个动画的运行,在动画的过程中,不需要新的 Main Frame 输入: 内核动画,每一帧都是由 Blink 生成,都需要产生一个新的 Main Frame: 2.1 合成器动画 合成器动画又可以分