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和半解决方案：我发现这篇文章讨论了四种主要的CSS选择器及其效率。我强烈推荐阅读，这篇文章帮助我搞清楚了如何最好地解决我的超媒体查询CSS问题。

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

- MikeZ

---

大量的媒体查询绝对会增加文件大小（它怎么可能不会呢？），从而影响下载所需的时间。 - cimmanon

感谢@cimmanon的快速回复，但文件大小的影响并不是我想要的。更具体地说，我想了解在DOM准备就绪后，网站性能、响应能力和浏览器资源使用方面的信息。 - MikeZ

那就进行一次性能测试并告诉我们结果吧？ - cimmanon

我无法直接回答你的绩效问题，但我倾向于建议采用“断点方法”来避免这个问题。同时，通过使用这个stackoverflow问题中的问题或答案中的方法，也可以对代码进行清理。 - ScottS

感谢@ScottS - 但是“断点”方法对我来说根本行不通。 我工作的网站非常定制化，我的客户不会接受任何不完全定制的网站。 我们以创建与“模板”和“盒子中的网站”有所区别的网站为荣。 - MikeZ

非常好的问题 - 我经常自己也在想这个。 - And Finally

Answer 1

几乎不可能给你一个完全准确的答案。 当询问性能时，典型的答案是对其进行分析并查看结果。先修复最慢的部分，然后重复执行。 您可以在Chrome开发者工具中分析CSS选择器。

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

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

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

关于文件大小和重复的CSS，gzip算法几乎完全抵消了这一点，因为gzip算法在处理重复数据时效果最佳。

- Petah

---

谢谢@Petah。我还在等待有人发布一个工具，可以实时评估特定CSS选择器的效率。你的答案非常有帮助，特别是提到了Google的最佳实践。 - MikeZ

Answer 2

> 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;

}

}

- Sunil R.