大体积css拖慢关键路径，因其是渲染阻塞资源，浏览器必须完整下载、解析并构建cssom才能渲染，非首屏样式（如未用动画、hover态）也会被强制加载解析，无法异步绕过，100kb比30kb多耗80–120ms cssom构建时间。
因为浏览器必须下载、解析并构建完整的 CSSOM 才能开始渲染页面，CSS 文件体积越大，网络传输耗时越长，CSSOM 构建越慢，首屏时间（FCP）和可交互时间（TTI）就越晚。
为什么大体积 CSS 会拖慢关键路径
CSS 是渲染阻塞资源。哪怕只多出 50KB 的非首屏样式（比如未用的动画、@media 查询、组件 hover 状态），也会被浏览器强制加载并解析——它无法像 JS 那样被 async 或 defer 绕过。实测显示：100KB 的 CSS 比 30KB 多消耗约 80–120ms 的 CSSOM 构建时间（尤其在中低端移动设备上）。
Less 编译产物膨胀的常见源头
Less 本身不运行在浏览器里，所有体积问题都来自编译输出失控：
-
@import无控制：比如@import "components/*.less"或重复@import "mixins.less"，导致同一段规则被多次展开 -
.extend()失效却没察觉：当被继承的选择器来自@import (reference)文件时，它根本不输出，.btn:extend(.icon)就退化为复制整套声明 - 嵌套过深：
.a { .b { .c { .d { color: red; } } } }生成的选择器是.a .b .c .d，不仅冗余，还触发浏览器更慢的选择器匹配 - 变量和 mixin 在循环中展开：如
.gen(@i) when (@i > 0) { ... .gen((@i - 1)); }若未设上限，可能生成数百个类名
如何快速验证是否真被 CSS 体积拖累
别猜，用浏览器 DevTools 的 Coverage 面板直接看：
- 打开「More Tools → Coverage」，刷新页面
- 查看
style.css对应的使用率，低于 90% 就说明大量 CSS 是白下、白析、白构 - 特别注意
:hover、@keyframes、@font-face是否被全局@import (reference)文件意外引入——它们会被每个引用该文件的入口重复输出
真正难处理的不是“怎么压缩”，而是“哪些样式本就不该出现在这个请求里”。Less 编译不出错，不代表产出合理；体积没报错，不等于没拖慢用户。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
