[译文]CSS的渲染性能
来源:互联网 发布:网络玄幻小说家排名 编辑:程序博客网 时间:2024/04/27 19:24
原文链接:Efficiently Rendering 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提高渲染性能具体的实现方法
- 从浏览器的渲染原理讲CSS性能
- 利用浏览器CSS渲染原理写出高性能的CSS代码
- 前端性能优化之-css阻塞渲染
- <CSS Transforms>译文
- 渲染性能
- [译文]CSS的水平/垂直居中:一篇完整的指南
- 渲染性能:读写style对渲染过程的影响
- 彩虹的性能特点 (官方站《Feature Overview》译文)
- 译文:前端性能的重要性 The Importance of Frontend Performance
- Warp : Haskell 的高性能 Web 服务器(译文)
- 如何用css制作有趣的按钮(最新译文)
- 提高 flash /air 的显示渲染性能
- ExtJS14:GoogleChart渲染的性能优化
- Intent的使用
- 棋盘问题 --dfs加回溯
- MATLAB 实现轨迹分类(路径分类)
- 用模板类迭代器实现顺序表
- MyBatis-逆向工程
- [译文]CSS的渲染性能
- 单例模式学习笔记
- Mybatis(输出映射)
- boost 库asio网络接口收取数据缺失的分析
- 第十周 项目5-用二叉树求解代数表达式
- 第一天:浪迹天涯网上商城(1.0版本)--项目介绍
- 剖析Disruptor:为什么会这么快?(一)锁的缺点
- 08cms安装出错 MYSQL错误:MySQL服务器正在使用–secure-file-priv选项运行,因此无法执行此语句
- 每次看见逃离,我想说我想逃离二线小城市