所谓“资源瀑布流优化”，本质是控制浏览器请求资源的时机与顺序，不是靠JS模拟视觉瀑布流；而DOM构建节点同步问题，根本上是脚本执行阻塞了HTML解析——两者常被混为一谈，但解决路径完全不同。
直接说结论：所谓“资源瀑布流优化”，本质是控制浏览器请求资源的**时机与顺序**，不是靠 JS 模拟视觉瀑布流；而 DOM 构建节点同步问题，根本上是脚本执行阻塞了 HTML 解析——这两者常被混为一谈，但解决路径完全不同。
资源加载的“瀑布流”其实是浏览器的自然行为，不能也不该被“优化”成串行
浏览器对 <link rel="stylesheet">、<script src>、<img> 的发起顺序，由 HTML 中标签出现位置决定，这是标准的“关键请求瀑布流”。你看到 DevTools Network 面板里请求逐个落下，不是 bug，是设计使然。
真正要干预的，是那些**不该等前面资源完成才发起**的请求：
-
<link rel="preload">必须放在<head>里，且只用于当前页面**立即需要**的资源（如首屏字体、关键 CSS、首图）；写成rel="prefetch"就会延后到空闲时，失去意义 -
async脚本不阻塞 DOM 构建，但执行时仍会暂停解析；defer才真正在 DOM 构建完成后执行——如果你的脚本操作的是document.body，用async可能报Cannot read property 'appendChild' of null - 图片懒加载别只靠
loading="lazy"：Safari 15.4 前不支持，且它依赖 IntersectionObserver，若首屏 item 过早触发滚动监听，可能漏加载；稳妥做法是给首屏<img>去掉loading属性，其余再加
DOM 构建被阻塞的典型现象和定位方法
页面白屏时间长、首屏文字迟迟不出现，大概率是同步脚本卡住了 HTML 解析。常见错误包括：
立即学习“前端免费学习笔记（深入）”；
- 把
<script src="xxx.js">放在<head>末尾，且没加defer或async—— 浏览器必须下载、执行完才能继续解析后面的<body> - 内联脚本里写了
document.write()（已废弃），会清空整个文档重建，彻底打断构建流程 - CSS 文件过大或服务器响应慢，虽然不阻塞 HTML 解析，但会阻塞 **渲染树合成**，导致 DOM 已就绪却无法绘制——此时
DOMContentLoaded已触发，但用户仍看不到内容
快速验证：打开 DevTools → Elements 面板，看是否能实时看到新节点不断插入；如果卡在某个 <script> 标签后不动，就是它在阻塞。
DOM 节点同步问题：不是“不同步”，而是你没等对时机
很多开发者抱怨 “JS 拿不到刚插入的 DOM 节点”，其实不是 DOM 没构建完，是你执行 JS 的时机错了：
-
document.getElementById("xxx")在<script>出现在该元素**之前**时，返回null—— 这不是异步问题，是代码执行顺序问题 - 想确保节点存在，要么把脚本放元素后面，要么监听
DOMContentLoaded，而不是load（后者等所有资源包括图片加载完） - 动态插入节点后立即操作，别直接查
offsetHeight：需触发重排（如读取offsetTop），或用requestAnimationFrame延迟到下一帧
注意：document.createElement 创建的节点默认不在 DOM 树里，必须显式 appendChild 或 insertAdjacentElement 才生效；没插入就去查 clientWidth，永远是 0。
真实项目里最容易被忽略的点
资源加载优化容易陷入“加一堆 preload 和 prefetch”的误区，但实际起效的只有前 3–5 个；DOM 同步问题常被归因为“框架响应慢”，其实根源往往是一行没加 defer 的脚本，或一个没包裹的 <img> 导致 layout thrashing。真正的瓶颈，通常藏在最基础的 HTML 结构和脚本放置位置里。
