关键CSS内联需严格控制在首屏必需的最小集合，超10KB（未压缩）会延长TTFB、拖慢HTML解析、降低gzip效率，弱网下实测首屏慢400ms；工具提取易含冗余规则，须结合真实viewport、用户偏好动态过滤，并通过手动验证或AB测试判断是否值得内联。
关键CSS内联不是“越多越好”，而是必须控制在首屏渲染真正需要的最小集合里；超过约 10KB（未压缩）或阻塞 HTML 解析超过 200ms，收益就快速衰减甚至为负。
critical CSS体积超过10KB时为什么反而拖慢首屏
HTML 文件体积膨胀会直接延长 TTFB 和网络传输时间，尤其在弱网下；浏览器解析大块内联 CSS 本身也耗时，它和 HTML 字节流混在一起，无法并行解码；gzip 压缩率随重复模式减少而下降，内联后冗余声明（如多次出现的 box-sizing: border-box）反而降低压缩效率。
- 实测：内联 15KB CSS 后 HTML 体积增长 30%，3G 网络下首屏时间比外链 + preload 慢 400ms
- 工具默认提取常包含未触发的
@media (prefers-color-scheme: dark)规则，若页面未启用暗色模式，这些就是纯噪声 -
@font-face、@keyframes、重置类（如* { margin: 0; }）从不参与首屏绘制，但占体积不小
如何动态识别并剔除无效关键CSS规则
静态提取工具无法判断运行时媒体查询是否匹配、伪类是否激活、JS 是否动态插入内容。必须结合真实 viewport 尺寸与用户偏好做二次过滤。
- 用
critters时加参数--include-media="(min-width: 320px)"，排除超小屏无关规则 - 构建脚本中注入环境变量
IS_DARK_MODE=false，再运行提取，自动跳过@media (prefers-color-scheme: dark)块 - 对 CSS-in-JS 输出，改用
useInsertionEffect或 runtime injection，避免工具因类名哈希（如jsx-abc123）漏提 - 手动验证：DevTools → Elements → 删除内联
<style>标签，刷新看首屏是否错位；若有，说明漏了关键规则；若无变化，说明有冗余
HTTP/2环境下是否还值得内联critical CSS
当服务端已开启 Link: </styles.css>; rel=preload 且资源缓存命中率 >80%，内联基本无收益，甚至因 HTML 缓存失效导致更差体验。
立即学习“前端免费学习笔记（深入）”；
- 检查 Network 面板：若
styles.css请求状态码是200 (from memory cache)或304，说明缓存有效，内联可停 - AB 测试显示：内联后 LCP（最大内容绘制）提升
- 优先级排序：TTFB 优化 > 资源压缩 > 关键 CSS 内联；若 TTFB > 600ms，先调 CDN、DB、API，别动 CSS
真正难的不是“怎么内联”，而是判断“哪些该留、哪些该砍、什么时候该关”——这取决于你页面的动态性、用户设备分布、CDN 缓存策略，而不是工具默认配置。
