关键css必须内联在最顶部（紧贴后），否则因解析阻塞导致首屏白屏；需剔除@import、url()、@font-face等异步引用，体积控制在gzip后≤14.6kb，确保及时构建cssom参与首屏渲染。
关键CSS必须放在 最顶部，紧贴 <meta charset> 之后；放错位置，哪怕只差一个 <script></script>，FMP 就会退回白屏状态。
为什么 <style></style> 必须在
浏览器按 HTML 字节流顺序解析，遇到第一个阻塞渲染的资源（比如 <link rel="stylesheet">）就暂停 DOM 构建和绘制。如果关键 CSS 的 <style></style> 前面插了任何脚本、或另一个未匹配 media 的 <link>，它就无法及时参与首屏 Render Tree 构建。
常见翻车点：
- 在
<style></style>前加了统计用的<script></script>—— 即使是内联脚本，也会阻塞 parser，延迟关键 CSS 生效 - 把
<style></style>放在<link rel="stylesheet" href="reset.css">后面 —— 浏览器先卡在 reset.css 加载上，首屏样式根本等不到 - 用了
<link rel="preload" as="style">却没配onload或后续<link rel="stylesheet">—— preload 只下载不解析，等于没做
<link rel="stylesheet"> 的 media 属性怎么设才不干扰首屏？
默认 media="all" 是强阻塞；但只要改成当前不匹配的值（如 media="print" 或 media="(min-width: 1024px)"），浏览器就会跳过加载，直到你手动切换 media 值才触发请求 —— 这正是非关键 CSS 异步加载的核心机制。
实操要点：
- 首屏必需的 CSS 必须走内联，不能依赖
media切换——它没有“立刻生效”的路径 - 非关键 CSS 推荐写法：
<link href="non-critical.css" rel="stylesheet" media="print" onload="this.media='all'"> - 别用
media="(max-width: 768px)"这类可能匹配移动端的值——iPhone SE 视口是375x667，这个查询会命中，照样阻塞 - 降级必须加：
<noscript><link rel="stylesheet" href="non-critical.css"></noscript>，否则 JS 失败时样式永久丢失
内联 CSS 里写 @import 或 url() 会发生什么？
会退化为同步网络请求，直接让内联失效。浏览器解析到 @import 'theme.css' 或 background: url(logo.png) 时，会立即发起新请求，并暂停当前 <style></style> 解析，直到该资源返回并解析完成。
后果比外链还糟：
- 多一次 TCP 往返（TTFB + 下载），实测拖慢 FCP 300ms+
- 无法被
preload提前发现，也不进 HTTP/2 Server Push 范围 - DevTools Network 面板里看不到 initiator 是
parser，而是css，排查更隐蔽 - 所有背景图、字体引用、动画帧都得剔除——
@font-face和@keyframes也禁止出现在内联块中
体积超限后，HTML 解析本身反而变慢
Chrome 明确建议内联 CSS 控制在 2KB（未压缩）以内。超过这个阈值，HTML parser 的 tokenization 阶段开销开始上升；实测超过 10KB 时，HTML 解析耗时反超外链 CSS 下载时间。
不是“越大越好”，而是“刚好够用”：
- 用
critters或vite-plugin-critical提取时，务必指定--viewport 375x667，否则桌面端规则混入，体积虚高 - 禁用网络后刷新页面，能显示的元素对应的选择器才保留；
.modal-overlay、.sidebar-nav这类隐藏节点样式一律剔除 - CSS-in-JS 动态类名（如
jsx-abc123）工具基本识别不了，要么改用运行时注入，要么在 JS 里提前写死静态类供提取 - 最终内联块建议用
gzip后 ≤14.6KB为硬上限——这是 HTTP/2 单个 TCP 包的理想尺寸
真正难的不是“怎么塞进去”，而是“哪些该塞、塞多少、塞完怎么确保不被后面的东西拖垮”。每一步都有确定性行为，但错一步，优化就变成负优化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
