直接内联 Critical CSS 是目前唯一能绕过 CSS 渲染阻塞、把 FCP 压到 300ms 内的手段，但需确保其位于 <head> 最顶部、体积≤14KB、按真实移动端视口提取，并配合 media="print" 加载非关键 CSS 以避免 FOUC。
直接内联 Critical CSS 是目前唯一能绕过 CSS 渲染阻塞、把 FCP 压到 300ms 内的手段——前提是它真被用在首屏 DOM 上，且体积没超载。
critical CSS 必须放在 <head> 最顶部，且在任何 <link rel="stylesheet"> 之前
浏览器解析 HTML 时，一旦遇到 <link rel="stylesheet"> 就会暂停渲染，直到该 CSS 下载并构建完 CSSOM。哪怕你已经在前面内联了 critical CSS，只要后面跟了一个未处理的 <link href="app.css">，整个首屏仍会被卡住。
- 错误顺序：
<style>...</style>→<link href="app.css">→ 白屏持续到 app.css 加载完 - 正确顺序：
<style>...</style>→ （非关键 CSS 用media="print"或rel="preload"） - SSR 场景下，若用
ReactDOMServer.renderToString生成 HTML，需确保 hydration 前的 DOM 结构与真实首屏一致，否则提取的 critical CSS 会漏掉动态 class（如.is-loaded）
提取 critical CSS 不能靠“猜”，得按真实视口跑覆盖率分析
用宽屏尺寸（比如 1920×1080）提取后直接用于手机端，结果常是塞进一堆 @media (min-width: 1200px) 规则，体积虚高、命中率低，甚至导致移动端首屏文字重叠。
- 移动端优先：模拟
width: 375, height: 667（iPhone SE）或width: 414, height: 896（iPhone 12） - 工具选型看构建链：Vite 用
vite-plugin-critical；Webpack 用critters；静态站用criticalCLI命令行工具 - 必须过滤掉
@font-face、@keyframes和display: none元素的样式——它们不参与首屏渲染，放进去只拖慢 TTFB
内联后非关键 CSS 怎么加载才不闪屏
单纯删掉 <link> 标签会导致响应式断点、暗色模式等逻辑失效；直接用 loadCSS() 插入又容易 FOUC 或样式抖动。
立即学习“前端免费学习笔记（深入）”；
- 推荐方案：
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">—— 浏览器默认不加载 print 样式，onload 触发后才激活 - 更稳妥做法：在
DOMContentLoaded后动态插入，或配合requestIdleCallback避免抢占主线程 - 别用
@import：无论写在<style>里还是外部 CSS 中，都会触发同步网络请求，实测拖慢 FCP 300ms+
内联体积超 14KB 就可能得不偿失
HTTP/2 下单个 TCP 包的理想大小是 14KB（gzip 后），超过这个值，解析开销反而上升，TTFB 增加，FCP 不降反升。
- 检查方式：提取后用
gzip -c critical.css | wc -c算实际传输体积 - 常见超载原因：误把
normalize.css或框架基础样式全量内联；没剔除伪类（如:hover）和未触发的媒体查询规则 - HTML 缓存策略要同步调整：
Cache-Control: max-age=3600，否则 critical CSS 更新后用户无法及时看到效果
真正难的不是“怎么内联”，而是判断哪些样式在真实设备、真实网络、真实用户交互路径下——确实被首屏 DOM 用到了。人工判断几乎必漏，工具链也得配对视口和 DOM 快照，否则优化就变成负优化。
