内联css不需提取，仅需在顶部正确放置、体积≤2kb（未压缩）、剔除非首屏规则及@import/url()，否则反增解析负担。
内联CSS在HTML解析阶段不触发任何额外提取——它根本不需要“提取”，而是随HTML字节流同步解析。所谓“提前提取”是误用概念，真正影响FMP的是它是否在正确位置、是否参与首屏渲染、体积是否突破解析瓶颈。
内联CSS根本不存在“提取时机”，只有“解析时机”
浏览器没有独立的“内联CSS提取器”。<style></style>块内容从HTML parser接收到第一个字节起，就和DOM构建并行进入CSS解析流程。它不像能被preload scanner提前发现，也不像@import要等CSSOM中途暂停去fetch——它就是HTML文本的一部分。
- 放在
顶部的<style></style>，会在解析到该标签时立即交由CSS引擎处理，无需等待HTML结束 - 若
<style></style>写在里（如某些CMS模板），则要等到解析到那个位置才开始解析，此时DOM可能已建大半，但CSSOM仍会阻塞后续渲染 - 工具如
critters生成的内联内容，本质是把一段CSS字符串注入HTML模板，注入点决定解析起点，不是“提取后插入”
体积超标会直接拖慢HTML parser本身，不是CSS解析慢
Chrome明确建议内联CSS控制在2KB（未压缩）以内，超过这个阈值，HTML parser的tokenization阶段就会明显变慢——这不是CSS引擎卡住，而是主解析线程在逐字节处理过长的<style></style>文本。
- 实测：10KB内联CSS在低端Android设备上，HTML解析耗时比2KB版本多出40–60ms，而CSSOM构建时间只差8ms
- gzip后14.6KB是理论安全上限，但前提是服务器必须开启gzip且客户端支持；若CDN或中间代理未透传Content-Encoding，实际传输仍是10KB明文，parser照卡
-
<style></style>里含@import或url()（如background: url(/img/logo.png)）会触发同步请求，此时内联完全失效，退化为阻塞式外链加载
首屏无关规则内联后反而延长FMP
内联的收益只来自“省掉一次网络请求”，但代价是增大HTML体积、延长TTFB、增加parser负担。如果内联内容里混入了非首屏规则，这些成本全付出了，收益却没拿到。
- 常见冗余：全局重置（
* { box-sizing: border-box }）、未触发的伪类（.btn:hover）、暗色模式媒体查询（@media (prefers-color-scheme: dark)）但页面默认亮色 - 动态类名陷阱：CSS-in-JS生成的
jsx-abc123类，critical工具无法匹配真实DOM中的class属性，导致提取结果为空或错漏 - 验证方法：禁用网络后刷新页面，仅靠内联CSS能否完整呈现首屏所有文字、按钮、图片占位框？不能，则说明缺规则；能，但页面滚动后样式错乱，则说明内联了不该内联的规则
真正难的不是把CSS塞进<style></style>，而是在构建流程中稳定捕获“此刻此viewport下实际生效的最小规则集”，并确保它永远比HTML parser的吞吐能力更轻。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
