FCP被CSS阻塞主因是浏览器必须等CSSOM构建完成才能生成Render Tree，即使1KB外链CSS也因TTFB和串行请求拖慢FCP；内联关键CSS需控制在2KB内，仅含首屏样式，避免@font-face等非必要规则。
CSS加载直接影响FCP，不是因为体积大，而是因为浏览器必须等CSSOM构建完成才能生成Render Tree——哪怕只有1KB的外链CSS，也会阻塞首次内容绘制。
为什么默认阻塞FCP
CSS是渲染阻塞资源（render-blocking resource），浏览器在解析HTML时遇到，会暂停构建Render Tree，直到对应CSS下载、解析、生成CSSOM。这个过程和DOM解析并行，但最终合成必须等待两者就绪。即使CSS文件很小，网络往返延迟（TTFB）或单次请求排队也足以把FCP从0.5s拖到2s+。
-
FCP触发前提是“首个内容节点完成绘制”，而该节点能否绘制，取决于它是否在Render Tree中；Render Tree又依赖CSSOM - 哪怕只有一条
.header { color: #333 }写在外链CSS里，且该<h1>在首屏，FCP就卡在这儿 -
@import更糟：它在CSS内部发起新请求，无法被preload干预，且强制串行执行
内联关键CSS的实操边界在哪里
内联能消除HTTP请求，但不是越多越好。Chrome建议首屏关键CSS控制在**2KB以内**（未压缩），否则HTML体积膨胀反而影响HTML解析速度，甚至触发移动端带宽限速。
- 只内联真正参与首屏元素样式的规则：比如
.logo、.hero-title、.primary-cta，不包含.modal-content或.sidebar-nav - 避免内联含
@font-face、@keyframes或大量媒体查询的CSS——它们不参与首屏渲染，却拉高HTML体积 - Vite用户可用
rollupOptions.output.manualChunks配合critical插件提取，Webpack推荐puppeteer+critters自动化生成
preload + onload切换样式链的坑
用<link rel="preload" as="style" href="critical.css" onload="this.rel='stylesheet'">看似优雅，但实际有三个易忽略问题：
立即学习“前端免费学习笔记（深入）”；
- 如果
critical.css加载失败，onload不触发，样式永久丢失——必须加<noscript><link rel="stylesheet"></noscript>降级 - 动态插入的
<link rel="stylesheet">仍会阻塞后续JS执行（因浏览器需保证CSSOM就绪后才运行脚本），所以async脚本要放在该link之后 - 某些CDN或代理会忽略
as="style"的preload提示，导致预加载失效；可配合fetchpriority="high"增强信号（Chrome 112+）
构建工具里cssCodeSplit ≠ 首屏按需
Vite设build.cssCodeSplit: true只是把CSS从JS chunk里拆出来，生成index.css、foo.css等独立文件——但默认仍全量引入index.css，没解决首屏阻塞。
- 真正起效的是结合
import('./modules/foo.css')+ 动态插入逻辑，例如用const link = document.createElement('link')手动挂载 - Webpack中
mini-css-extract-plugin默认只按入口拆分，若想组件级分离，必须配React.lazy或defineAsyncComponent，否则CSS仍打进main.css - 别迷信
contenthash：哈希再稳定，如果main.css还是120KB，FCP照样卡住
最常被跳过的动作，是没验证“哪些CSS真被首屏元素用到”——靠肉眼判断容易高估，用Chrome DevTools的Coverage面板（Ctrl+Shift+P → “Coverage”）打开，刷新页面，看.css文件里哪些代码是灰色未使用，这才是真实的关键CSS范围。
