CSS选择符由一些初始化参数组成,这些参数指明了要应用这个CSS规则的页面元素。作为一个网站的前端开发工程师,应该避免编写一些常见的开销很大的CSS选择符模式,尽量编写高效的CSS选择符,从而加快页面的渲染速度,缩短页面呈现时间。

我们先来看一下safari和webkit的架构师David Hyatt的两段话:

  1. 样式系统从最右边的选择符开始向左进行匹配规则。只要当前选择符的左边还有其他选择符,样式系统就会继续向左移动,直到找到和规则匹配的元素,或者因为不匹配而退出
  2. 如果你非常在意页面的性能那千万别使用CSS3选择器。实际上,在所有浏览器中,用 class 和 id 来渲染,比那些使用同胞,后代选择器,子选择器(sibling, descendant and child selectors)对页面性能的改善更值得关注。

Google 资深web开发工程师Steve Souders对CSS选择器的效率从高到低做了一个排序:

1.id选择器(#myid)2.类选择器(.myclassname)3.标签选择器(div,h1,p)4.相邻选择器(h1+p)5.子选择器(ul < li)6.后代选择器(li a)7.通配符选择器(*)8.属性选择器(a[rel=”external”])9.伪类选择器(a:hover,li:nth-child)

上面九种选择器中ID选择器的效率是最高,而伪类选择器的效率则是最底。详细的介绍大家还可以点击Writing efficient CSS selectors

综合上面的顺序,我们清楚的知道,id和类名用于关键选择器上效率是最高的,而CSS3的仿伪类和属性选择器,虽然使用方便,但其效率却是最低的

知道了基本原理以后,我们编写CSS时就应该注意了。下面举几个例子,让大家理解的更透彻一些:

1.不要在编写id规则时用标签名或类名

  1. BAD
  2. button#backButton {…}
  3. BAD
  4. .menu-left#newMenuIcon {…}
  5. GOOD
  6. #backButton {…}
  7. GOOD
  8. #newMenuIcon {…}

由于样式系统从最右边的选择符开始向左进行匹配,只要当前选择符的左边还有其他选择符,样式系统就会继续向左移动,直到找到和规则匹配的元素,或者因为不匹配而退出,所以,在button#backButton {…}中,样式系统先找到id为backButton的元素,然后继续向左匹配,查看该元素的标签名是不是button,如果不是,查找下一个id为backButton的元素,再检查这个元素的标签名,如此周而复始,直到到达文档末尾。如果只是#backButton {…},则样式系统找到id为backButton的元素后,因为左边没有其他选择符了,它就退出而结束查找了。

另外,根据HTML规范,id在HTML中是唯一的,也就是说一个HTML页面只限定有一个id为“XX”的元素,而不限制拥有这个ID元素的标签名,所以,在button#backButton {…}中,button标签完全是无意义的,可以,而且应该去掉,button#backButton {…}与#backButton {…}是等价的。在#backButton前多写了button,只会引起样式系统向左移动,继续查找页面元素,损耗页面性能,延长页面渲染时间。

另一方面,在id元素前面添加标签名,还会引起另一个致命的问题,比如原来id为backButton的标签名是button,如果原来样式声明写成button#backButton {…},则现在需要把button标签改成input,id不变,则button#backButton {…}声明的样式规则在这个id同样为backButton的input元素上不起作用,不信大家可以自己动手编写试一下。

2.不要在编写class规则时用标签名

  1. BAD
  2. treecell.indented {…}
  3. GOOD
  4. .treecell-indented {…} //语言化和标签名绑在一起 假设treecell
  5. BEST
  6. .hierarchy-deep {…} //语言化和标签名无关

原理参考第一条。

3.把多层标签选择规则用class规则替换,减少css查找

  1. BAD
  2. treeitem[mailfolder=”true”] > treerow > treecell {…}
  3. GOOD
  4. .treecell-mailfolder {…}

4.避免使用子选择器

现在我们来看看David Hyatt的第3段话:后代选择器在CSS中是最昂贵的选择器。贵得要命——尤其是把它和标签或通配符放在一起!

  1. BAD
  2. treehead treerow treecell {…}
  3. BETTER, BUT STILL BAD (see next guideline)
  4. treehead > treerow > treecell {…}

标签后面最好永远不要再增加子选择器

  1. BAD
  2. treehead > treerow > treecell {…}
  3. GOOD
  4. .treecell-header {…}
  5. BAD
  6. treeitem[IsImapServer=”true”] > treerow > .tree-folderpane-icon {…}
  7. GOOD
  8. .tree-folderpane-icon[IsImapServer=”true”] {…

5.依靠继承

  1. BAD
  2. #bookmarkMenuItem > .menu-left { list-style-image: url(blah) }
  3. GOOD
  4. #bookmarkMenuItem { list-style-image: url(blah) }

最后,我们来做个总结,网站编写CSS时,应该优先考虑使用class选择器,避免使用通配符选择器(*)和属性选择器(a[rel=”external”]),后代选择器与标签选择器结合使用也应避免。使用id选择器的性能最好,但是编写时要注意其唯一性,谨慎使用。CSS3选择器(例如::nth-child(n)第n个孩子)在帮助我们锁定我们想要的元素的同时保持标记的干净和语义化,但事实是,这些花哨的选择器让更多的浏览器资源被密集使用。引用David Hyatt关于CSS3选择器的论述:如果你关心页面性能的话,他们真不该被使用!

  1. 英文文档参考资源:
  2. http://blog.archive.jpsykes.com/151/testing-css-performance/
  3. http://blog.archive.jpsykes.com/152/testing-css-performance-pt-2/
  4. http://blog.archive.jpsykes.com/153/more-css-performance-testing-pt-3/
  5. Testing CSS Performance  Jon Sykes
  6. https://developer.mozilla.org/en-US/docs/CSS/Writing_Efficient_CSS?redirectlocale=en-US&redirectslug=Writing_Efficient_CSS
  7. •Original Document Information
  8. •Author: David Hyatt
  9. •Original Document Date: 2000-04-21
  10. •Original Document URL: http://www.mozilla.org/xpfe/goodcss.html
  11. http://css-tricks.com/efficiently-rendering-css/
  12. (Efficiently Rendering CSS)
  13. https://developers.google.com/speed/docs/best-practices/rendering?hl=zh-CN
  14. (google建议)

Web前端性能优化WPO,相信大多数前端同学都不会陌生,在各自所负责的站点页面中,也都会或多或少的有过一定的技术实践。可以说,这个领域并不缺乏成熟技术理论和技术牛人:例如Yahoo的web站点性能优化黄金法则,以及大名鼎鼎的优化大师Steve Souders。本文并非一篇讨论性能优化技术方法的文章,而更多的是对中文站搜索List页面持续两年多的前端性能优化实践的思路总结。希望对正在从事这个领域研究的前端同学能有所帮助。

简单的说,我们的性能优化实践分为三个阶段:初探期、立规期、创新期, 每个阶段大概持续半年左右,有足够的时间形成一些优化思路的沉淀。

一:初探期 

2010年底我们开始接手搜索List页面,这是中文站历史最为悠久的页面之一,当时它的生命体征正如它的年龄一样,非常虚弱:当时的基调网络监控显示,页面的完全加载的时间是16秒!作为以“快”为核心业务指标的搜索页面,这个状态显然已是无法承担重任了。

性能是一定要优化的,但我们也面临着大多数前端同学所面临的共性问题 — 业务需求紧张,况且我们是刚刚接手这个业务,非常不熟悉,别说是优化了,就是做个小需求也都经常出现线上故障。就是在这样的情况下,我们开始了搜索页面的性能优化之路,并且给自己定下了当时看起来非常难以实现的目标:在2011年年中前把全页面加载时间降低到7秒以下。

我们很快成立了一个性能优化小组,3-4个前端同学参与其中,一个人的力量毕竟有限,尤其是应对这样一个历史业务繁多的页面。参与的同学多些,技术氛围也相对浓烈,大家很全面的分解了目前页面上出现的性能瓶颈,并分别领取了自己的优化任务。

在这个阶段里,我们基本是照葫芦画瓢,把雅虎性能优化的那些法则与我们的页面一一对照,完成了许多优化点,例如:

  • 小图片的合并,形成CSS Sprite,并优化图片
  • 模块的异步加载
  • 图片的懒加载
  • CSS文件引用放在页面顶部,JS文件引用放在页面底部,并对代码压缩
  • 缩小cookie体积
前人的技术理论果然是靠谱,经过我们半年时间加班加点的性能优化后,我们奇迹般的达成了优化目标!(附性能曲线图)

查看更多