内联CSS超过14KB会触发额外TCP往返：超出初始拥塞窗口（约14.6KB）导致分包传输、RTT延迟增加，gzip压缩率下降15%~30%，缓存失效频发，且易因构建疏漏引入冗余内容。
内联CSS超过14KB会触发额外TCP往返
浏览器加载HTML时，初始拥塞窗口（Initial Congestion Window）通常限制在约14.6KB（未压缩）。如果内联的
gzip压缩率下降导致传输体积反弹
内联CSS混在HTML里，会破坏CSS文件原本高度可压缩的结构（比如重复的选择器、属性、空格）。HTML本身压缩率本就低于纯CSS，当大量样式被塞进HTML后，整体gzip压缩率常下降15%~30%。更糟的是，某些CDN或Nginx配置会为text/html禁用高级压缩（如brotli），而对text/css启用，进一步放大体积劣势。
缓存失效让每次请求都传冗余样式
外部CSS文件能被独立缓存，更新时只需传输新版本；而内联CSS绑定在HTML里，只要HTML模板有任意改动（比如加个class、改个文案），整个HTML就得重新下载——连带那几KB关键CSS也被重复传一遍。常见场景：A/B测试页、带时间戳的活动页、CMS动态生成页，都会让内联CSS失去复用价值。
构建与部署环节容易误操作
很多人用脚本自动提取Critical CSS，但没做体积兜底检查。结果是：
立即学习“前端免费学习笔记（深入）”；
- 提取逻辑把
@font-face、@keyframes甚至整段background-image: url(...)都塞进内联块 - 构建产物未剔除已内联部分，导致外部CSS里还留着相同规则，白占体积
-
ponytail或critical工具默认不压缩内联内容，输出含大量空格/注释
这些都会让内联后的HTML比预期大出2–3倍，却没人盯着最终index.html大小。
真正卡住性能的从来不是“该不该内联”，而是“内联多少”和“内联之后怎么管”。一旦越过14KB红线，又没配好缓存与压缩，内联就从加速器变成拖油瓶。
