DOM与CSSOM构建是首屏渲染的协同阻塞环节：CSSOM未完成则DOM不进入布局，而阻塞脚本又拖慢CSSOM生成；需通过内联关键CSS、分离非首屏样式、规避@import等手段错峰裁剪，实现可控协同。
DOM 构建和 CSSOM 解析是页面首屏渲染的两个阻塞环节，它们不并行、不独立——CSS 解析完成前，DOM 树无法进入布局阶段；而 DOM 中未闭合或含阻塞脚本的节点，又会拖慢 CSSOM 的生成。关键不是“分别优化”，而是控制它们的协同节奏。
DOM 解析被 <link rel="stylesheet"> 中断的真实机制
浏览器遇到 <link rel="stylesheet"> 时，并不会“暂停 HTML 解析”，而是继续构建 DOM 树（部分节点可生成），但会将后续的 DOM 节点标记为“未激活”——这些节点暂不参与样式计算、不加入渲染树，直到对应的 CSSOM 就绪。这意味着：
- 放在
<head>中的 CSS 文件越长、解析越慢，首屏可见内容（尤其是<body>开头的元素）的渲染延迟就越明显 - 多个
<link>会串行下载（除非加media属性触发惰性加载），且每个都可能触发一次 CSSOM 重建 -
<style>内联块虽免下载，但若体积大（>1KB），仍会显著拉长 CSSOM 构建时间，且无法被缓存
CSS 中的 @import 是 DOM/CSSOM 协同的隐形杀手
@import 不只是语法糖，它在解析时强制引入一个“子请求链”：主 CSS 文件必须完全解析后，才发起 @import 的资源请求，且该请求完成后才能继续构建 CSSOM。这导致：
- 即使
@import指向的是本地 CSS，也会比并列的<link>多出至少一个事件循环延迟 - 嵌套
@import（如 A.css → @import B.css → @import C.css）会让关键渲染路径呈线性恶化 - 多数构建工具（如 Webpack、Vite）默认不处理 CSS 内的
@import，容易在开发期无感，上线后首屏变白屏
如何让 DOM 和 CSSOM “刚好同步”而不是互相等待
没有绝对的“同步”，只有可控的“错峰”与“裁剪”。实操上聚焦三点：
立即学习“前端免费学习笔记（深入）”；
- 把首屏必需的 CSS 提取为内联
<style>（注意控制在 1–2KB 内），用critical工具或手动提取，确保<body>开头的 DOM 节点能立刻参与渲染 - 非首屏 CSS（如模态框、分页组件）用
media="print"+onload切换，或通过rel="preload"提前加载但延迟应用 - 避免在
<head>中混写<script>（尤其未加async或defer的），因为 JS 执行会中断 DOM 解析，间接延长 CSSOM 等待窗口
真正难的不是知道该做什么，而是判断哪段 CSS 属于“首屏必需”——它取决于视口尺寸、设备 DPR、是否开启字体加载策略，甚至用户滚动速度。这类动态边界，没法靠静态分析穷尽，必须结合真实设备上的 Performance 面板中 Layout 和 Recalculate Style 时间戳交叉验证。
