内联 critical css 可将移动端 h5 的 fcp 压至 300ms 内，但需满足：置于 最顶部、无阻塞资源、精准覆盖真实首屏样式（含动态 class、暗色模式、移动端视口），体积 ≤1kb 且不含 @import/url()；否则白屏更长。
内联 Critical CSS 在移动端 H5 上能压低 FCP 到 300ms 内，但前提是它真被浏览器立刻解析、不被其他资源阻塞、且覆盖了真实首屏所有样式——否则白屏时间反而更长。
critical CSS 必须放在 <link rel="stylesheet">
浏览器解析 HTML 时，一旦遇到 <link rel="stylesheet"> 就会暂停渲染，直到该 CSS 下载并构建完 CSSOM。哪怕你已经在它前面写了 <style></style>，只要后面跟着一个未处理的 <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） - 暗色模式站点需显式保留
@media (prefers-color-scheme: dark)下的关键规则，否则首屏闪白/闪黑 - 工具选型看构建链：
vite-plugin-critical（Vite）、critters（Webpack）、criticalCLI（静态站） - 务必过滤掉
@font-face、@keyframes和display: none元素的样式——它们不参与首屏渲染，放进去只拖慢 TTFB
内联体积必须 ≤1KB（弱网场景），且禁用 @import、url()、@font-face
内联 CSS 是 HTML 的一部分，体积过大 → 单次 TCP 包无法装下 → 需要额外 RTT 才能收全 → 首屏渲染延迟反增。移动端弱网下 RTT 波动大，1KB 是实测较稳妥的阈值；超过 2KB 就明显增加白屏风险。
- 含
@import、url(/bg.jpg)、未处理的@font-face，这些仍会发起新请求并阻塞整条规则应用 - 纯 CSR（客户端渲染）项目基本无效：首屏 DOM 是空的，critical 工具提取结果基本为空或严重误判
- JS 动态添加 class（如
.active）而内联 CSS 没覆盖这些状态样式，会导致首屏视觉错乱 - 验证方式只有一种：DevTools Network 面板勾选 Offline 后刷新，看首屏文字/按钮/色块是否仍正常显示
非关键 CSS 必须用 media="print" + onload 切换，不能直接删 <link>
单纯删掉 <link> 标签会导致响应式断点、暗色模式等逻辑失效；直接用 loadCSS() 插入又容易 FOUC 或样式抖动。
- 推荐写法：
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">—— 浏览器默认不加载 print 样式，onload触发后才激活 - 更稳妥做法：在
DOMContentLoaded后动态插入，或配合requestIdleCallback避免抢占主线程 - 别用
@import：无论写在<style></style>里还是外部 CSS 中，都会触发同步网络请求，实测拖慢 FCP 300ms+ - HTTP/2 环境下内联收益下降——多路复用已缓解请求开销，此时更应关注资源拆分与缓存策略
最难的不是“怎么内联”，而是每次加新组件、改媒体查询、切暗色模式时，都得重新验证 critical CSS 是否还覆盖真实首屏路径——漏一条 .header-nav a:hover，就可能让导航栏文字重叠或错位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
