嵌套选择器性能影响和 LESS答案

【问题标题】：Nested selectors performance impact and LESS嵌套选择器性能影响和 LESS
【发布时间】：2012-11-29 13:53:19
【问题描述】：

过去 1.5 小时我一直在阅读这方面的内容，但仍然找不到简明扼要的决定性答案。

据我了解，浏览器从右到左解析 CSS 选择器。

这意味着像这样的长 CSS 选择器：

.card .container .businesscard .pinfo li.pinfo-box span:first-child

是 SO 中出现过的效率最低的代码行之一。

首先，我说的对吗？

其次，我正在使用 LESS 设计一个丰富的 UI，它最终会从我正在编码的嵌套设计中产生这种庞大的选择器。

可以做些什么来避免这种选择器？仅依靠类和 ID？但话说回来，如果你不会写嵌套的 CSS，那么使用 LESS 的目的是什么？

感谢您的意见。

【问题讨论】：

听起来你把选择器复杂化了。该选择器中是否需要.container？如果.container 不是它的祖先之一，你真的打算让span:first-child 的样式不同吗？
我明白了。我想我嵌套得太深了。
奇怪的是，昨天有人问了一个关于 Sass/SCSS 的类似问题：stackoverflow.com/questions/13805324/…
嗯。我可能确实找到了它，因为我正在搜索 LESS。谢谢 - 它有一些很棒的信息。
也就是说，是否可以增强 LESS 解析器以分解嵌套和优化选择器？例如将其限制为 3 个级别的顶部。比这更深，它会从右到左破坏提取物巢。可能的？可靠的？你怎么看？

标签： css performance optimization css-selectors less

【解决方案1】：

没错。浏览器从右到左评估选择器。它将尝试在li.pinfo-box 中查找span，依此类推。

编写 LESS 时要遵循的一条经验法则是：嵌套层数不要超过 3-4 层。

这将防止您的选择器变大，而您仍然可以从 LESS 中的嵌套功能中受益。

“无用”嵌套的一个很好的例子是样式列表。有时我会这样写选择器：

#wrapper .blog-post ul, #wrapper .blog-post ul li

真的有必要指定li 必须在ul 内吗？大概写够了：

#wrapper .blog-post li

所有这些都很高兴知道。但是：在尝试优化您的网站性能时，这不是首先要深入研究的事情。花一些时间减少请求的数量或其他东西。

【讨论】：

感谢您的提示。我们还没有一个工作站点，目前只是设计 UI。您可能想在答案开头更正“从左到右”:)

【解决方案2】：

除非您有非常不寻常的内容，否则选择器解析和匹配不太可能是一个重要因素。我建议使用任何可维护的东西并完成工作，直到测试显示性能问题为止。然后我会拿出一个分析器（在 OSX 上我会使用 Instruments，但大多数平台应该有一个不错的）并将它附加到浏览器；如果选择器匹配在配置文件中显示很高，那么考虑用更快的选择器替换慢速选择器（id 选择器绝对是一个不错的选择）。

【讨论】：

这很有趣 - 我以前从未使用过这样的工具。我会在 Windows 上寻找一个。谢谢！