css文件阻塞渲染导致白屏，因浏览器会暂停dom构建和布局直至css加载解析完成，以确保javascript调用getcomputedstyle等api时样式就绪；关键css需内联或preload，非关键css可用media属性异步加载。
为什么 CSS 文件阻塞渲染会导致白屏
浏览器遇到 <link rel="stylesheet"> 时，会暂停构建 DOM 树和布局（layout），直到该 CSS 加载并解析完成。这不是 bug，而是设计使然——因为 JS 可能调用 getComputedStyle() 或查询元素尺寸，必须确保样式表就绪。所以哪怕 HTML 已下载完，只要关键 CSS 没到位，页面就「卡住」不绘制，表现为白屏。
常见错误现象：
首屏内容明显延迟出现；FMP（First Meaningful Paint）指标差；Lighthouse 报告提示“Eliminate render-blocking resources”；移动端弱网下白屏长达 2–3 秒。
- 关键 CSS 必须内联或预加载，不能依赖外部
<link>异步加载 - 非关键 CSS（如打印样式、暗色主题切换逻辑）可用
media属性隔离，例如<link rel="stylesheet" href="print.css" media="print">，这类资源不会阻塞初始渲染 - 不要在
里混写<script></script>，尤其未加defer的脚本，它会进一步拖慢 CSS 解析时机
如何安全地异步加载非关键 CSS
想让非关键 CSS 不阻塞首屏，但又不能用 rel="preload" 后直接执行（会引发 FOUC 或竞态），得靠 rel="stylesheet" + media 切换的组合技。
使用场景：主题切换 CSS、动画库样式、第三方组件样式（如地图控件）、响应式断点补丁。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 初始设
media="print"，让它加载但不生效：<link rel="stylesheet" href="theme-dark.css" media="print" onload="this.media='all'"> - 用
onload回调把media改为"all"，触发应用；IE 不支持onload，需 fallback 到onreadystatechange - 避免用
fetch()+insertRule()动态注入，CSS 规则优先级易失控，且无法利用浏览器预加载器
preload 和 prefetch 在 CSS 场景下的误用
preload 是告诉浏览器“马上需要这个资源”，而 prefetch 是“将来可能需要”。对 CSS 来说，只有 preload 有意义，但必须配 as="style"，否则浏览器不会提升优先级。
容易踩的坑：
- 写了
<link rel="preload" href="main.css">却漏掉as="style"，结果资源被当成普通脚本下载，优先级反而更低 - 在
里放preload，部分浏览器（如 Safari）会忽略 - 对已内联的关键 CSS 再
preload外部同名文件，造成重复请求和缓存错乱 -
prefetch不适合 CSS，它没有触发时机控制，常在空闲时才下载，起不到优化首屏的作用
服务端注入关键 CSS 的边界在哪里
内联关键 CSS（Critical CSS）确实能消灭白屏，但不是越多越好。超过 14KB 的内联样式会增加 HTML 体积，影响 TTFB 和首字节时间，尤其在 HTTP/1.1 下更明显。
性能权衡点：
- 只提取首屏可见区域（above-the-fold）真正用到的选择器，工具如
penthouse或critters可自动化，但需配合真实 viewport 尺寸配置 - 避免内联
@import、字体声明（@font-face）、CSS 变量定义（除非 JS 确实依赖），它们无法被浏览器有效缓存 - 如果站点有多个模板（如商品页 / 文章页 / 首页），关键 CSS 应按页面类型拆分，而不是塞进一个全局
critical.css
最麻烦的地方其实是缓存失效策略——HTML 变了，内联 CSS 就得重提，但没人真去维护这套联动。所以实际项目里，宁可多压 100ms 白屏，也别让构建流程因 Critical CSS 变脆弱。
