使用 CSS 子选择器会更快吗?

Posted

技术标签:

【中文标题】使用 CSS 子选择器会更快吗?【英文标题】:Would it be faster to use a CSS Child Selector? 【发布时间】:2014-11-02 06:25:27 【问题描述】:

如果我们想定位段落中的链接,哪个选择器会更高效/更快?

p a

p > a

【问题讨论】:

我怀疑p > a,但时间可能可以忽略不计。你的基准测试是怎么说的? 更多,ie6不支持子选择器.. 今天唯一关心 IE6 的人可能已经知道了。 有一个答案,现已删除,提到两个选择器做完全不同的事情,因此不应仅通过性能进行比较。我不明白为什么它会被视为“无用”或无关紧要。鉴于 htmlpa 元素的性质,您会发现自己处理 a 元素的可能性是 p a 但不是 p > a 并不是微不足道的。而且,根据 Niels Keurentjes 的回答,我可以保证您会在这个特定的选择器成为瓶颈之前很久就遇到这种情况。 我的回答得出的结论确实应该是——永远不要在问题出现之前解决问题。 CSS 成为现实性能问题的可能性是如此之低,以至于与所有过早的微优化相比,出现错误的机会根本不值得。编写正确的声明,并在完成的站点开始出现瓶颈时消除它们。不过,我认为这个问题在本质上更具理论性,并不是开始偏爱一个而不是另一个的真正意图。 【参考方案1】:

让我给你看一下选择器的效率顺序,从最快到最慢,这是google的一些结论:

    id 选择器 (#myid) 类选择器 (.myclassname) 标签选择器 (div,h1,p) 邻居选择器 (h1+p) 子选择器(ul>li) 后代选择器 (li a) 星选择器 (*) 属性选择器 (a[rel="external"]) 伪类选择器(a:hover,li:nth-child)

它可能并不完全正确,并且不适用于各种浏览器,但这个顺序仍然可供参考。希望对您有所帮助!

要了解有关 CSS 性能的更多信息,请参阅:http://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

【讨论】:

我为什么要相信一个随机的、带有一些糟糕术语的随机列表作为权威? @BoltClock 这对于所有浏览器可能并不准确。我只是参考别人的结论。欲了解更多信息,请参阅:benfrain.com/… 如果您指的是不是您写的东西,您需要引用复制的内容并在答案中引用来源。请参阅***.com/help/referencing 事后不要等待其他人提示您链接到源,否则有人会假设您自己编写了它(就像我之前所做的那样)。 感谢@BoltClock指出问题,我已经改进了答案,以后会更认真。 @BoltClock 我非常感谢您的讽刺言论。您的含义非常清楚,不需要任何详细说明。【参考方案2】:

第二个(非常)快一点。 CSS 由浏览器反向处理,因此您的两个规则都在页面上的所有 a 元素上进行了测试。对于第二条规则,它只需要测试直接父级,对于另一条规则,它需要测试整个后代链。

在实践中,除非您在具有相同多行 HTML 的页面上获得数以万计的此类数据,否则执行时间差异在统计上并不显着。

【讨论】:

你的意思是整个祖先链,对吧?听起来我很挑剔,但这让我困惑了一秒钟。

以上是关于使用 CSS 子选择器会更快吗?的主要内容,如果未能解决你的问题,请参考以下文章

jQuery 选择器优化

评估 CSS 选择器 LTR 或 RTL 是不是更容易/更快?

需要向包含“保存”按钮的 <p> 添加一些 CSS,选择器会是啥样子? [复制]

CSS父选择器定义了宽度 子选择器宽度要和父选择器一样 需要再定义宽度吗。如果子选择器再定义宽度,

为啥第 n 个子选择器会选择这些元素?

课时73.后代选择器和子元素选择器(理解)