关键不是压缩CSS体积，而是让浏览器尽快获取首屏所需CSS；需用media属性条件加载、动态导入非首屏样式、避免@import、合理分割CSS、删除冗余选择器、谨慎内联并控制体积在2KB内。
怎么让CSS不阻塞页面渲染
关键不是“压缩体积”，而是让浏览器尽快拿到首屏需要的那部分CSS。默认会阻塞HTML解析和首次绘制，哪怕只有1KB，也会拖慢FCP（首次内容绘制）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
media属性做条件加载，比如<link rel="stylesheet" href="print.css" media="print">，非匹配媒体类型时不会阻塞渲染 - 对非首屏样式（如模态框、折叠菜单）用
rel="preload"+as="style"预加载，再用JS动态插入<link rel="stylesheet"> - 避免在
<head>里写@import——它会串行加载，比<link>多一次HTTP往返，且无法被preload或media控制
CSS代码分割：哪些工具能真正起作用
Webpack、Vite、esbuild这些构建工具确实支持CSS提取，但“分割”不等于“按需加载”。很多配置只是把CSS从JS里抽出来，仍是一整块main.css，首屏还是全量下载。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- Vite用户优先用
rollupOptions.output.manualChunks配合cssCodeSplit: true，再结合import('./modules/foo.css')动态导入（注意：需搭配style标签插入逻辑） - Webpack中
mini-css-extract-plugin默认只按入口拆分，要实现组件级CSS分离，必须配合import()+React.lazy或defineAsyncComponent，否则CSS仍打进主包 - 不要依赖
contenthash或chunkhash来“优化缓存”——如果首屏CSS体积没降，哈希再稳也没用
压缩CSS真能省多少？别信gzip后的数字
gzip后main.css从120KB压到30KB，不代表浏览器解析快了4倍。解析和构建CSSOM的时间取决于选择器复杂度、规则数量，而非字节数。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 删掉
/* comment */和空行对gzip影响极小，优先砍的是冗余选择器（比如div.container ul li a:hover缩成.nav-link:hover） - 禁用
cssnano的mergeLonghand和normalizeWhitespace——它们可能把margin: 0 1em转成margin: 0 1em 0 1em，反而增大体积 - 用
critters（Vite插件）或critical（CLI）提取关键CSS并内联，比单纯压缩更直接有效；但注意：它不能自动识别“首屏”，得靠你配include路径或penthouse截图分析
为什么inline CSS有时比外链还慢
内联<style>确实免去了HTTP请求，但会污染HTML缓存，且无法被CDN边缘缓存复用。更重要的是，一旦内联内容变大，HTML响应体变长，TTFB和首字节时间都会上升。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只内联
max-width: 768px以内、无JS交互依赖的纯布局/字体/颜色规则，体积控制在2KB以内（Chrome建议阈值） - 避免内联含
@font-face或url()的规则——base64字体可能让HTML暴涨几十KB，且字体文件无法单独缓存 - 服务端渲染（SSR）场景下，内联CSS必须和服务端生成的HTML严格同步；若前端hydration时CSSOM不一致，可能触发强制重排，比外链还卡
真正卡住性能的，往往不是“有没有压缩”，而是“哪部分CSS必须立刻执行”。拆分粒度、加载时机、选择器效率，三者缺一不可。很多人调完cssnano就以为结束了，其实才刚摸到门把手。
