浏览器默认阻塞渲染是为了避免fouc，确保样式确定后再渲染；遇会暂停html解析、推迟dom构建，直至cssom就绪，即使小文件也会因网络延迟导致白屏。
为什么 <link rel="stylesheet"> 默认阻塞渲染
浏览器在解析 HTML 时，遇到 <link rel="stylesheet"> 就会暂停 DOM 构建，转而下载、解析 CSS 并构建 CSSOM —— 因为渲染树（Render Tree）必须同时依赖 DOM 和 CSSOM，缺一不可。这意味着：哪怕只有一行未加载的 CSS，整个首屏内容就无法绘制，用户看到的就是白屏或延迟 FCP。
常见错误现象包括：DOMContentLoaded 延迟 >1s、Lighthouse 报 “Eliminate render-blocking resources”、FCP >1.2s 且页面无文字/按钮可见。
- CSS 是“渲染阻塞资源”，和它放在
还是无关，只和是否被浏览器识别为“关键样式”有关 - 即使 CSS 文件很小（如 2KB），若未内联且走网络请求，仍可能因 TCP 握手、TLS 协商、队列排队引入 200–600ms 延迟
- 多个
<link>串行加载时，后一个要等前一个 CSSOM 构建完才开始下载（尤其在旧版 Safari 中更明显）
哪些 CSS 算“关键”，哪些可以推迟
“关键 CSS”指首屏（above-the-fold）内容渲染所必需的样式规则：比如 header、hero-banner、main-title、首屏按钮/表单的尺寸、颜色、显示状态。其余都属于“非关键”——例如折叠区域、分页器、footer、暗色模式备用类、动画帧定义。
使用场景决定划分边界：单页应用中，路由切换后的“新首屏”可能需要动态注入新关键 CSS；静态博客首页的关键 CSS 通常固定，但文章页需单独提取。
- 不要靠人工 eyeball 判断：用 Chrome DevTools → Coverage 标签，刷新后勾选 “CSS”，看首屏渲染实际用到哪些规则（通常只占全部 CSS 的 15–30%）
- 避免把整份
main.css内联进 HTML：体积超 14KB 可能触发 iOS Safari 的内联 CSS 解析降速 - 媒体查询可天然隔离关键性：
<link rel="stylesheet" href="print.css" media="print">不会阻塞屏幕渲染
三种落地方式的取舍：内联 vs preload vs media
目标不是“去掉 CSS”，而是让浏览器在最短时间内拿到首屏所需的样式字节。三种主流手段各有适用条件：
-
内联关键 CSS：直接写进 HTML 的
<style></style>标签里。适合首屏样式稳定、不常更新的站点；缺点是无法利用 HTTP 缓存，每次 HTML 变更都要重新传输样式 -
<link rel="preload" as="style">：提前发起 CSS 请求，但不执行；需配合onload注入或media="print"+ JS 切换，否则仍会阻塞。适合关键 CSS 体积较大（>10KB）、或需服务端动态生成的场景 -
media 属性降级：
<link rel="stylesheet" href="non-critical.css" media="only x">，初始不匹配，不阻塞；JS 加载完再切回 <code>media="all"。兼容性好（IE9+），但多一次 JS 执行开销
注意：preload 不等于 prefetch；后者是低优先级预取，对 CRP 无效。
容易被忽略的连锁影响
改了 CSS 加载方式，JS 行为可能意外变化。比如：
- 原本依赖 CSSOM 就绪的
getComputedStyle()调用，在内联 CSS 后可能提前执行，但此时 layout 尚未完成，返回值不准 - 使用
document.styleSheets遍历样式表的代码，在preload+ 动态注入路径下，需监听load事件而非仅靠DOMContentLoaded - 服务端渲染（SSR）框架如 Next.js 或 Nuxt，默认已做关键 CSS 提取，手动再内联可能导致重复注入，引发样式闪烁或 specificity 冲突
真正卡住 CRP 的，往往不是某一行代码，而是对“谁需要什么、什么时候需要、浏览器怎么调度”的误判。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
