CSS内联经验法则：多大体积的CSS适合内联？

嘿，这个问题问到点子上了——很多前端开发者都会卡在“到底多大的CSS适合内联”这个点上。我结合自己的实践和行业里的性能测试结论，给你梳理下：

• 通用经验法则：压缩后15KB以内
  这是Google、Web.dev还有Lighthouse这类性能工具默认推荐的阈值。为什么是15KB？主要和HTTP/1.1的初始连接窗口、以及现代浏览器对首屏资源的加载优先级有关——压缩后的15KB CSS，基本能保证在首屏渲染的关键路径里快速加载完成，不会因为体积过大拖慢首次内容绘制（FCP）。而且这个大小的内联代码，也不会让HTML文件膨胀到影响缓存或解析的程度。

• 性能测试的实际依据
  不少性能团队做过对比测试：当内联CSS超过15KB（压缩后）时，HTML文件的体积会显著增加，导致浏览器下载和解析HTML的时间变长，反而抵消了内联CSS避免渲染阻塞的优势。尤其是在移动端低带宽环境下，这个负面影响会被放大。Lighthouse的性能审计规则里，也会把超过这个大小的内联CSS标记为“过大的内联样式”，提示你拆分非关键部分到外部文件缓存。

• 别死磕字节数，核心是“关键CSS”
  其实字节数只是参考，更重要的是你内联的是不是首屏关键CSS——也就是渲染首屏内容必须用到的样式。哪怕你的关键CSS有20KB，但全是首屏必需的，那内联它依然是合理的；反过来，如果10KB的内联CSS里有一大半是 footer、弹窗这类首屏看不到的样式，那还不如把这部分提取成外部文件让浏览器缓存。

• 自定义调整的思路
  如果你想更精准，完全可以自己做测试：用Web Vitals工具监控LCP（最大内容绘制）、FCP这些核心指标，逐步调整内联CSS的大小，看什么时候指标最优。比如你的用户群体主要在高带宽地区，那阈值可以适当放宽；如果是移动端为主，可能10KB以内会更稳妥。

总结一下：15KB（压缩后）是行业通用的安全线，但最终要结合自己的页面关键CSS范围和用户场景来定，始终以实际性能指标为准。

内容的提问来源于stack exchange，提问作者Illidan