少，媒体查询和性能

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＆amp;半解决方案：我找到了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算法最适合重复数据。

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;

}

}