内联 Critical CSS 是目前唯一能绕过 CSS 渲染阻塞、把 FCP 压到 300ms 内的手段，须置于 <head> 最顶部、体积≤14KB（gzip 后）、按真实移动端视口（如375×667）提取，过滤 @font-face/@keyframes/display:none 样式，并用 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）
按真实移动端视口提取，别用桌面尺寸“猜”
用宽屏尺寸（比如 1920×1080）提取后直接用于手机端，结果常是塞进一堆 @media (min-width: 1200px) 规则，体积虚高、命中率低，甚至导致移动端首屏文字重叠。
- 移动端优先：模拟
width: 375, height: 667（iPhone SE）或width: 414, height: 896（iPhone 12） - 工具选型看构建链：
vite-plugin-critical（Vite）、critters（Webpack）、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 不降反升。
- extractCritical 返回空？大概率是传入的 HTML 没带真实样式资源，或
@import未提前展开，或 SSR 模板中 class 是占位符而非真实挂载态 - FOUC 更严重？不是 Critical CSS 的问题，而是内联块生效了，但原来的
<link>还在 DOM 里，浏览器先画一次再重绘一次 - 缓存策略要同步调整：HTML 文件本身成了样式缓存单元，需缩短
Cache-Control: max-age（比如设为 3600），否则样式更新无法及时生效
最容易被忽略的是视口匹配和缓存联动：同一份 critical CSS 用在不同设备上，要么命中率暴跌，要么体积失控；而 HTML 缓存时间拉太长，改了样式用户根本看不到。
