内联关键CSS是绕过浏览器渲染阻塞的刚性需求；必须精准提取首屏所需样式，控制体积≤1KB并紧贴<meta charset>后注入，否则仍会导致白屏或性能恶化。
因为不内联，首屏就必然白屏——浏览器必须等外部 CSS 下载解析完才能画任何带样式的节点，而内联是唯一能绕过这个硬性阻塞的手段。
内联是绕过浏览器渲染阻塞的刚性需求
浏览器构建渲染树前，必须同时完成 DOM 和 CSSOM。遇到 <link rel="stylesheet"> 时，HTML parser 会直接暂停，直到该 CSS 文件下载、解析完毕。这个过程无法被 async 或 defer 绕过，是渲染引擎级硬依赖。
哪怕只差一个 .primary-cta { background: #007bff } 没加载，整个首屏按钮、标题、色块都得等——在弱网（如 3G、IoT 设备）下，TTFB + 下载耗时轻松超 800ms，白屏就是秒级起跳。
内联后，这部分 CSS 随 HTML 一并到达，浏览器解析完 HTML 就能立刻构建 CSSOM 和 Render Tree，FCP/FMP 直接压到 300ms 内量级。
立即学习“前端免费学习笔记（深入）”；
为什么必须精准提取、不能手写或截开头几KB
人工判断基本不可靠，以下情况会让“看起来关键”的样式实际无效：
- 媒体查询不匹配：用
--viewport 1200x800提取，结果塞了一堆@media (min-width: 1200px)的导航栏规则，手机访问根本不用 - CSS-in-JS 动态类名（如
jsx-abc123）工具识别率极低，手动补又容易漏伪类（:hover）、暗色模式（@media (prefers-color-scheme: dark)） - 把
@font-face、@keyframes、display: none区块的样式也塞进去，白白增大体积却不参与首屏绘制
实操建议：critters（Webpack/Vite 插件）或 critical CLI 必须指定真实设备视口，例如 --viewport 375x667（iPhone SE），并开启 --minify 后手动检查输出是否含 url() 或 @import。
内联位置和体积控制不当，反而拖慢首屏
再准的 CSS，放错位置或超重，FMP 反而更慢：
-
<style>必须紧贴<meta charset>之后，前面不能有同步脚本或document.write()，否则 parser 直接中断，<style>根本不解析 - 体积建议 ≤1KB（未压缩），超过 2KB 会明显拖慢 HTML parser；超过 10KB 时，HTML 解析耗时甚至反超外链 CSS 下载时间
- 严禁在
<style>中写@import或url()（如背景图），它们仍会触发同步网络请求，退化为新的阻塞点
构建流程中，内联 CSS 应作为独立产物（如 critical.css）由模板引擎注入，而非硬编码进 HTML 源码——否则 CDN 缓存污染、AB 测试版本错配问题频发。
验证是否真生效，只有一种方式
别信构建日志、Lighthouse 报告或“看起来快了”。唯一可靠验证方法：
- 打开 Chrome DevTools → Network 面板 → 勾选
Offline - 刷新页面
- 观察首屏文字、按钮、轮播图容器是否仍正常显示（颜色、尺寸、定位）
如果出现空白、错位、默认字体或无样式按钮，说明内联内容不匹配真实首屏渲染路径，或者被其他阻塞点（如残留的 <link rel="stylesheet">）覆盖了。这时候优化就只是自我安慰。
