我最近开始使用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.
解决方法
几乎不可能给你一个完全准确的答案.
当询问性能时,典型的答案是配置它,看看你得到什么.首先修复最慢的部分,然后重复.
您可以在Chrome开发人员工具中设置CSS选择器：
最终,我认为媒体查询对于性能的影响与即使是稍微复杂的选择器相比也不会有任何影响.
您可以在这里查看有关编写高效CSS的更多信息：
https://developers.google.com/speed/docs/best-practices/rendering
还有关于文件大小和重复的CSS,gzip几乎完全取消了这一点,因为gzip算法最适合重复的数据.
