内联首屏关键css能显著压低fmp，因为其随html一并到达，省去外链css的ttfb、下载与解析三阶段，使浏览器解析完html后立即构建cssom和render tree，从而加速主要内容渲染完成。
内联首屏关键CSS能显著压低FMP，但前提是提取准、放得对、体积控得住——错一步，FMP反而更慢。
为什么内联CSS能加速FMP
FMP依赖“主要内容渲染完成”，而浏览器必须等CSSOM就绪才能绘制任何带样式的节点。外链CSS哪怕只有1KB，也要经历TTFB + 下载 + 解析三阶段，期间HTML解析可能已结束，但Render Tree卡住不动。内联
- 关键路径缩短：从“HTML → CSS请求 → CSS下载 → CSS解析 → Render Tree”变为“HTML（含CSS）→ 解析 → Render Tree”
- 不依赖TCP初始拥塞窗口：只要内联
- 对移动端尤其有效：3G/4G下TTFB常超200ms，省掉这一跳直接把FMP从1.2s拉到300ms量级
提取关键CSS时最常踩的三个坑
很多人用工具一键生成，却没验证是否真影响首屏内容。FMP只认“实际参与首屏渲染的规则”，不是“看起来重要的选择器”。
- 用
critters或criticalCLI时，必须指定真实设备视口，比如--viewport 375x667（iPhone SE），否则提取出的规则可能包含桌面端导航栏样式 - 手动验证方法：禁用网络后刷新页面，还能显示的元素（如
.hero-title、.primary-cta）对应的选择器才值得保留；.modal-overlay、.sidebar-nav这类隐藏或非首屏元素的样式必须剔除 - 遇到CSS-in-JS生成的动态类名（如
jsx-abc123），工具基本无法识别，建议改用运行时注入，或提前在JS里写死静态类名供提取
内联位置和体积控制的硬性边界
再准的CSS，放错位置或超重，都会拖累FMP。浏览器按顺序解析，
-
<style></style>必须放在最顶部，紧贴<meta charset>之后，前面不能有阻塞脚本或大块JS - 体积上限是
2KB（未压缩）或14.6KB（gzip后）——Chrome官方推荐前者，因为超过2KB会拖慢HTML parser本身；实测超过10KB时，HTML解析时间反超CSS下载时间 - 严禁在
<style></style>里写@import或url()（如背景图），它们会触发同步网络请求，直接退化为阻塞源
异步加载剩余CSS时的FMP干扰点
内联完关键CSS后，剩余样式必须异步加载，但方式不对会重新阻塞FMP或TTI。
- 用
<link rel="preload" as="style" href="rest.css" onload="this.rel='stylesheet'">时，如果rest.css加载失败，onload不触发，样式永久丢失——必须配<noscript><link rel="stylesheet" href="rest.css"></noscript>降级 - 动态插入
<link rel="stylesheet">仍会阻塞后续<script></script>执行（浏览器需保证CSSOM就绪），所以async脚本要放在该<link>标签之后 - 某些CDN（如Cloudflare免费版）会忽略
as="style"，建议加fetchpriority="high"增强信号，仅Chrome 112+支持
真正影响FMP的从来不是“有没有内联”，而是“内联了什么、放在哪、多大、怎么补全”。一个.header { color: #333 }写在外链里，就足以让FMP卡住；而一段超重的内联CSS，会让HTML解析变慢，得不偿失。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
