直接内联Critical CSS是压低FCP至300ms内的唯一有效手段，但需确保提取精准、体积可控（
直接内联 Critical CSS 是目前唯一能绕过 CSS 渲染阻塞、把 FCP 压到 300ms 内的手段——但前提是提取准、体积小、位置对、后续不冲突。
提取 critical CSS 为什么总为空或漏样式
extractCritical 返回空字符串，或者生成的 CSS 里全是 .modal-hidden、.dropdown--closed 这类根本没在首屏出现的规则，不是工具坏了，而是输入不对。
- 工具默认不解析远程
，如果 HTML 里只写了但本地没提供该文件路径或返回 404，就啥也提不出来 - SSR 渲染的 HTML 若含动态 class（比如
class="btn is-loading"），而工具跑的是未 hydration 的模板快照，is-loading样式就会被跳过 -
@import没提前用 PostCSS 展开，critters 直接忽略整条规则；@font-face和含url()的声明也会被跳过或导致阻塞
实操建议：用 fs.readFileSync('dist/style.css', 'utf8') 把完整 CSS 字符串显式传给提取函数；确保 HTML 输入是已渲染完成的快照（如 Puppeteer 截图后保存的 HTML），而非原始模板。
内联位置和顺序错一个字符就白屏
哪怕 critical CSS 提取得再准，只要它没放在 最顶部，或者后面紧跟着一个没处理的 ，浏览器照样卡住不动。
- 错误写法：
→→ 白屏直到 app.css 加载完 - 正确写法：
→ - 必须从 HTML 中彻底移除所有被提取覆盖的
标签，不能“留着备用”
注意：data-critical 不是可选装饰，是后续清理、调试、CI 自动校验的关键标记。
内联内容里藏着三个隐形阻塞点
内联不是把 CSS 字符串塞进去就完事。 里的某些语法仍会触发同步网络请求或解析延迟，让首屏变慢而不是变快。
- 含
@import：实测拖慢 FCP 超 300ms，且无法被 preload 或异步控制 - 含
@font-face或url(/img/hero.jpg)：这些请求会卡在 CSSOM 构建阶段，整条规则暂停应用 - 混入
@keyframes或display: none元素的样式：不参与首屏渲染，纯属体积累赘，gzip 后超 1KB 就可能触发额外 RTT
实操建议：提取后手动 grep 验证 —— grep -n '@import\|@font-face\|url(' critical.css；用 csso 或 clean-css 压缩时加 --keep-breaks=false 防止注释残留。
验证是否真有效，别信工具输出
工具日志显示 “critical CSS extracted: 942 bytes”，不代表它真起作用。唯一可靠验证方式是模拟最差网络条件看首屏是否还能成形。
- 打开 Chrome DevTools → Network → 勾选
Offline→ 刷新页面 - 观察首屏文字、按钮边框、背景色块是否正常显示；若有空白、重叠、错位，说明关键样式漏了或 media 查询没覆盖当前设备
- 特别检查暗色模式用户：
@media (prefers-color-scheme: dark)下的color、background是否也在内联块中
真正难的不是“怎么提取”，而是每次加新组件、换断点、上 AB 实验时，都得重新跑一遍 viewport=375×667 的覆盖率分析——漏掉一个 .card--featured，首屏就可能闪白半秒。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
