[译文]CSS的渲染性能
2017-11-04 13:42
204 查看
原文链接:Efficiently Rendering CSS
我承认,我不经常考虑下面这个问题:我们写的CSS如何才能
这的确是浏览器厂商应该考虑的问题:页面加载越快,人们更愿意使用它们的产品。Mozilla 有一篇关于CSS开发的最佳实践(译者注:原文链接已失效)。谷歌(尝试)改进(浏览器)让网页加载地更快。
让我们来浏览它们阐述的主要观点,然后讨论这些观点的实践性。
第一个被解释的部分是:a[title=’home’]。第一个部分被认为是
下面的选择器按照解释的速度快慢排序
当我们结合从右到左解释和关键选择器的原理,我们会发现下面这个选择器不是最有效率的。
即使(事实)让人觉得古怪的,反直觉的……因为ID选择器是如此地有效以至于我们会认为浏览器能够快速地找到那个ID,然后快速地找到我们需要它的子节点。但是事实是:上面代码中的标签选择器被先解释。
ID是唯一的,所以不需要一个标签和ID同时存在。这么写CSS选择器让选择器效率更低。
同理适用于类选择器。尽管类选择器不是唯一的,理论上多个不同的元素可能有相同的类名。如果你想要style视元素的不同而定,你可能需要tag-qualify(标签限制),比如
后代选择器是CSS中开销最大的选择器。它在标签选择器和通配符选择器就更加昂贵了。
换而言之,下面的选择器就是一个效率灾难
font-family是级联的(译者注:可继承的。)所以你可能不需要这么非常具体的选择器。这个选择器是可以改进,变得更有效率:
CSS3选择器,比如(:nth-child),在帮助我们定位元素,并且保持标签整洁和语义化方面,是非常棒的。但是事实是:使用这些奇妙的选择器是浏览器资源密集型的。
所以我们不应该使用它们吗?让我们考虑下实践性。
这个就是我的结论:我们上述的最佳实践不再有意义了。当然你也可以遵循这些最佳实践,因为它们没有限制你的CSS开发能力。但是你没有必要将这些实践奉为教条。如果你处于这么一个职位:你需要从边边角角挖掘站点的最后一丝性能潜力,那么值得review你的CSS代码,去看看哪里可以做得更好。如果你没有提升站点渲染速度的需求,那么不要担心CSS的效率,向前看吧。
我承认,我不经常考虑下面这个问题:我们写的CSS如何才能
有效率的,换而言之,如何才能让浏览器更快地渲染它。
这的确是浏览器厂商应该考虑的问题:页面加载越快,人们更愿意使用它们的产品。Mozilla 有一篇关于CSS开发的最佳实践(译者注:原文链接已失效)。谷歌(尝试)改进(浏览器)让网页加载地更快。
让我们来浏览它们阐述的主要观点,然后讨论这些观点的实践性。
Right to left
有一件重要的事你需要知道:浏览器从右往左解析你的CSS选择器。那意味着在下面这个例子中:ul > li a[title='home']
第一个被解释的部分是:a[title=’home’]。第一个部分被认为是
key selector。
ID’s are the most efficient, Universal are the least
一共有4种选择器,它们分别是ID选择器,类选择器,标签选择器,通配符选择器下面的选择器按照解释的速度快慢排序
#main-navigation { } /* ID (Fastest) */ body.home #page-wrap { } /* ID */ .main-navigation { } /* Class */ ul li a.current { } /* Class * ul { } /* Tag */ ul li a { } /* Tag */ * { } /* Universal (Slowest) */ #content [title='home'] /* Universal */
当我们结合从右到左解释和关键选择器的原理,我们会发现下面这个选择器不是最有效率的。
#main-nav > li { } /* Slower than it might seem */
即使(事实)让人觉得古怪的,反直觉的……因为ID选择器是如此地有效以至于我们会认为浏览器能够快速地找到那个ID,然后快速地找到我们需要它的子节点。但是事实是:上面代码中的标签选择器被先解释。
Don’t tag-qualify
不要这么开发CSS语言:ul#main-navigation { }
ID是唯一的,所以不需要一个标签和ID同时存在。这么写CSS选择器让选择器效率更低。
同理适用于类选择器。尽管类选择器不是唯一的,理论上多个不同的元素可能有相同的类名。如果你想要style视元素的不同而定,你可能需要tag-qualify(标签限制),比如
li.first,但那是相当罕见的,所以一般,类选择和标签选择器不要同时使用。
Descendant selectors are the worst
David Hyatt后代选择器是CSS中开销最大的选择器。它在标签选择器和通配符选择器就更加昂贵了。
换而言之,下面的选择器就是一个效率灾难
html body ul li a { }
A selector that fails is more efficient than that same selector matching
我不确定,我们能否从这个原理中收获足够多。因为如果你有大量的选择器没有匹配任何元素,那是相当古怪的。但是有趣的是:在对选择器的从右到左的解释,一旦选择器匹配失败,它就停止尝试,减少了不必要的开销。Consider why you are writing the selector
思考下面的例子:#main-navigation li a { font-family: Georgia, Serif; }
font-family是级联的(译者注:可继承的。)所以你可能不需要这么非常具体的选择器。这个选择器是可以改进,变得更有效率:
#main-navigation { font-family: Georgia, Serif; }
CSS3的效率
David Hyatt:一个令人悲伤的真相:如果你关心页面的效率,那么CSS3选择根本不应该被使用。
CSS3选择器,比如(:nth-child),在帮助我们定位元素,并且保持标签整洁和语义化方面,是非常棒的。但是事实是:使用这些奇妙的选择器是浏览器资源密集型的。
所以我们不应该使用它们吗?让我们考虑下实践性。
Practicalities
基于一个事实:十年前的计算机是比不上现在的。我感觉,这个事情(CSS选择器的效率)在那个时候是比较重要的。我感觉:我们不再经常讨论CSS选择器的效率,因为它不再是一个大的问题。这个就是我的结论:我们上述的最佳实践不再有意义了。当然你也可以遵循这些最佳实践,因为它们没有限制你的CSS开发能力。但是你没有必要将这些实践奉为教条。如果你处于这么一个职位:你需要从边边角角挖掘站点的最后一丝性能潜力,那么值得review你的CSS代码,去看看哪里可以做得更好。如果你没有提升站点渲染速度的需求,那么不要担心CSS的效率,向前看吧。
Super-speed, Zero-practicality
我们知道:ID选择器是最有效率的选择器。如果你想使页面达到最高的渲染效率,你或许会想到给每个元素加上唯一的ID,然后通过ID选择器应用样式。那样,速度会更快,但也会超级可笑。这会使得代码及其非语义化,而且及其困难维护。你不会再任何基于性能的站点上看到这种方法。我认为,经验是:不要为了有效率的CSS的牺牲语义化和可维护性。相关文章推荐
- 从浏览器的渲染原理讲CSS性能
- 从浏览器的渲染原理讲CSS性能
- 使CSS渲染更高效性能优化介绍
- 前端性能优化之-css阻塞渲染
- 网页性能优化:防止JavaScript、CSS阻塞浏览器渲染页面
- css之提高渲染性能的写法
- 从浏览器的渲染角度讲解css性能
- CSS提高渲染性能具体的实现方法
- 从浏览器的渲染原理讲CSS性能
- 用CSS开启硬件加速来提高网站性能
- 移动端性能大比拼:CSS Sprites vs. Data URI
- 用事实证明cssText性能高
- CSS优化总结――网络性能与语法性能建议
- Vue服务端渲染和Vue浏览器端渲染的性能对比(实例PK )
- css硬件加速提升网页性能
- css渲染-2
- 网站性能优化和关键渲染路径
- 前端性能优化之浏览器加载、解析、渲染的过程
- NME中不同渲染方式的性能测试
- 如何使CSS渲染更高效