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

> also u can write like this :-

// breakpoints

@mobile:     ~"(max-width: 767px)";

@tablet:     ~"only screen and (min-width: 768px) and (max-width: 991px)";

@desktop:     ~"only screen and (min-width: 992px) and (max-width: 1199px)";

@desktop-xl:     ~"only screen and (min-width: 1200px) and (max-width: 1350px)";


body{
   background:black;
    @media @mobile {
       background:red;

}

}

Answer 2

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

当询问性能时，典型的答案是对其进行分析，然后看看你会得到什么。先修复最慢的部分，然后重复。

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

最终，我认为媒体查询对性能的影响不会像稍微复杂的选择器那样大。

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

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

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