将css媒体查询分组在一起是否有优势？

(这可能已经回答了 – 也找不到答案)

传统的@media查询覆盖倾向于将同一个包组下的一个大小/媒体的所有覆盖分组。

例如

.profile-pic {
    width:600px;
}
.biography {
    font-size: 2em;
}

@media screen and (max-width: 320px) {
    .profile-pic {
        width: 100px;
        float: none;
    }
    .biography {
        font-size: 1.5em;
    }
}

在Sass中，有一个非常漂亮的方法来在嵌套的声明中编写@media查询覆盖，像这样：

.profile-pic {
width:600px;
  @media screen and (max-width: 320px) {
    width: 100px;
    float: none;
  }
}

.biography {
    font-size: 2em;
  @media screen and (max-width: 320px) {
    font-size: 1.5em;
  }
}

现在，编译时，sass不会将@media查询块分组在一起，因此输出结果是这样的：

.profile-pic {
    width:600px;
}
@media screen and (max-width: 320px) {
  .profile-pic {
    width: 100px;
    float: none;
  }
}

.biography {
    font-size: 2em;
}
@media screen and (max-width: 320px) {
  .biography {
    font-size: 1.5em;
  }
}

我使用这种技术为一个最近的项目，当你应用这个原则到一个更大的项目，你最终与多个@media查询部分散布在整个css(我到目前为止约20个)。

我很喜欢sass技术，因为它使得更容易遵循覆盖的流程(并且也使它更容易移动的东西)。

但是，我想知道是否有任何缺点，有多个@media部分通过CSS，特别是性能明智？

我试过chrome css profiler，但我看不到任何特定于@media查询。

(More info on @media in sass on this page)

解决方法

晚了一点晚会，但基于下面的测试，性能影响似乎是最小的。该测试分别显示具有2000个单独和组合的媒体查询的示例页面的呈现时间。

http://aaronjensen.github.com/media_query_test/

主要的好处似乎是文件大小比任何其他 – 这，如果你压缩的CSS生产，将大大减少。

但最终，正如下面的链接帖子所说：

“If you have 2000+ media queries in your CSS,I think that you may want to reconsider your UI development strategy versus using a gem to re-process your CSS.”

详细介绍问题的博客文章：
http://sasscast.tumblr.com/post/38673939456/sass-and-media-queries