css - LESS、媒体查询和性能

Question

我最近开始使用 LessCSS，并且在我的 CSS 变得多么干净和可读方面取得了相当大的成功。但是，我认为我没有充分利用 Less。

我现在正在使用 Less 编写我的第一个完全响应式网站，我关心的是性能和速度。 需要注意的一件事 是我不坚持“断点”方法 - 我将事物放大和缩小直到它们断裂，然后我编写 CSS 来修复它们；这通常会导致 20 - 100 个媒体查询。

我想开始使用 Less 在我的元素中嵌套媒体查询，如下例所示:

.class-one {
    //styles here

    @media (max-width: 768px) {
        //styles for this width
    }
}
.class-two {
    //styles here

    @media (max-width: 768px) {
        //styles for this width
    }
}

通过我的初始测试，我发现在查看编译后的 CSS 输出时 - 这种方法会导致多个(很多!)@media (max-width: ___px) 实例。我搜索了互联网，但没有找到任何明确解释嵌套/冒泡媒体查询的性能影响的内容。

更新 1::我意识到更多的 CSS 信息会导致需要下载更大的 CSS 文件 - 但我并不像将网站加载时间作为唯一指标那样担心。我对 DOM 准备就绪后浏览器对内存和性能的处理更感兴趣。

更新 2 和半解决方案: 我找到了 this article which discusses the four main categories of CSS selectors and their efficiencies .我强烈推荐阅读这本书，它帮助我理清了如何最好地解决我的过度媒体查询的 CSS。

所以我的问题是:DOM 准备就绪后，我编译的样式表中有这么多媒体查询会影响加载时间和性能吗？

Answer 1

几乎不可能给你一个完全准确的答案。

当询问性能时，典型的答案是分析它并查看您得到的结果。先修复最慢的部分，然后重复。

您可以在 Chrome 开发者工具中分析 CSS 选择器:

最终，我认为媒体查询对性能的影响远不及稍微复杂的选择器。

您可以在此处查看有关编写高效 CSS 的更多信息:

https://developers.google.com/speed/docs/best-practices/rendering

此外，关于文件大小和重复 CSS，gzip 几乎 完全消除了这一点，因为 gzip 算法最适合处理重复数据。