CSS加载会阻塞渲染但不阻塞DOM解析，因渲染树需同时依赖DOM树与CSSOM树；内联关键CSS、preload切换、媒体查询降级可优化首屏性能。
CSS 加载会阻塞渲染，但不阻塞 DOM 解析
结论很直接：CSS 文件加载完成前，浏览器不会绘制任何内容（白屏），但 DOM 树仍在后台继续解析。这是因为渲染树（Render Tree）必须同时依赖 DOM 树和 CSSOM 树，缺一不可。
常见错误现象是——开发者看到 Network 面板里 HTML 已快速加载完毕，DOM 节点也出现在 Elements 面板中，但页面就是空白或只有部分文字裸奔；这就是 CSSOM 未就绪导致渲染被挂起的典型表现。
- CSS
<link>是“渲染阻塞资源”，无论放在<head>还是<body>中，只要在首次渲染前遇到，就会阻塞绘制 -
<style>内联样式不阻塞渲染，但若体积过大（如 6000+ 行），可能因 HTML 解析器边加载边解析而引发 FOUC（Flash of Unstyled Content） - 多个
<link rel="stylesheet">会按顺序阻塞：第二个必须等第一个 CSSOM 构建完才开始下载解析，形成串行瓶颈
为什么不能跳过 CSS 就渲染？
不是浏览器“故意卡你”，而是避免重绘浪费。如果先用默认样式画一遍，再等 CSS 加载后重算布局、重绘颜色尺寸，不仅性能差，用户还会看到内容“跳动”或“闪一下”。浏览器选择“等齐了再画”，本质上是一种确定性优化。
关键逻辑链：
HTML 解析 → DOM Tree<br>CSS 下载 + 解析 → CSSOM Tree<br>DOM Tree + CSSOM Tree → Render Tree → Layout → Paint
立即学习“前端免费学习笔记（深入）”；
- DOM 解析和 CSS 下载可并行（HTTP/1.1 多连接或 HTTP/2 多路复用下更明显），但 Render Tree 构建必须等待 CSSOM 就绪
- JS 执行也会被阻塞：若
<script>出现在<link>后，它必须等前面所有 CSS 加载并构建完 CSSOM 才能执行（哪怕 JS 本身不操作样式） -
DOMContentLoaded事件触发时机与 CSS 无关，但load事件会等所有 CSS 加载完成
如何绕过 CSS 渲染阻塞？实操三招
核心思路：让首屏关键样式“秒到”，非关键样式延后或异步加载。
-
内联关键 CSS：把首屏（Above-the-Fold）用到的样式提取出来，用
<style>直接写进<head>，避免额外请求。注意控制体积（建议 ≤ 14KB，避免影响 TCP 初始拥塞窗口） -
preload + onload 切换：用
<link rel="preload" as="style" href="main.css" onload="this.rel='stylesheet'">提前拉取 CSS，但不立即应用；配合<noscript>回退 -
媒体查询降级：对非视口样式（如打印、宽屏适配），用
media="print"或media="(min-width: 1200px)"声明，浏览器默认不阻塞，等条件匹配时再加载
容易踩的坑：defer / async 对 CSS 无效
很多人想当然给 <link> 加 async 或 defer，但这两个属性只对 <script> 生效，加在 CSS 上完全被忽略——浏览器会照常阻塞渲染。
另一个典型误操作：把 <link> 放到 <body> 底部以为能“不阻塞”，其实没用。只要它在首次绘制前被 HTML 解析器碰到，依然会触发阻塞（只是延迟了阻塞发生的时间点）。
真正起效的，永远是资源交付路径的调整，而不是标签位置的挪动。
