资源瀑布流是浏览器网络请求的时间序列图，反映请求发起时序而非渲染顺序；其“重叠”指html解析过程中并行发起多个请求，但实际生效受加载方式（async/defer）和阻塞关系制约，真正影响首屏渲染的是关键资源在html中的位置与加载策略。
资源瀑布流（Resource Waterfall）不是渲染结果，而是浏览器发起网络请求的时间序列图；它和 DOM 渲染有强时序耦合，但不决定渲染顺序——真正影响首屏可见性的，是资源在 HTML 中的出现位置、加载方式（async/defer）、以及是否阻塞解析。
资源瀑布流里“重叠”到底指什么
所谓“重叠”，是指浏览器在解析 HTML 过程中，并行发起多个资源请求（如 CSS、JS、图片），这些请求在网络时间线上部分或完全交叉。但这不等于它们会同时生效——CSS 文件即使早于 JS 下载完成，若 JS 是同步脚本，仍会阻塞 CSSOM 构建完成前的渲染。
常见误解：看到瀑布流里 style.css 和 app.js 请求时间重叠，就认为它们互不影响。实际上：
-
link rel="stylesheet"会阻塞后续script执行，哪怕 JS 已下载完 -
script（无async/defer）会暂停 DOM 解析，导致后续所有资源（包括图片）延迟触发请求 - 图片请求通常在 DOM 节点插入后才发起，所以
img标签位置靠后，其请求必然晚于前面的 CSS/JS
DOM 渲染何时开始？和瀑布流起点无关
浏览器不会等瀑布流“跑完”才开始渲染。只要解析出一部分可绘制的 DOM 节点（比如一个 div + 文本），且对应 CSSOM 已就绪（至少关键样式已解析），就会立即进入 Layout → Paint 流程。
这意味着：
- 首屏内容渲染快慢，取决于 HTML 前几 KB 是否包含可渲染结构 + 关键 CSS 是否内联或提前加载
- 瀑布流中靠后的资源（如底部广告 JS、非首屏图片）即使下载慢，也不影响首屏渲染完成时间
-
DOMContentLoaded触发时机，只取决于 HTML 解析完成 + 同步脚本执行完毕，与图片、字体等资源是否加载无关
怎么用瀑布流诊断真实渲染瓶颈
打开 Chrome DevTools → Network → 切换到 Waterfall 视图，重点看三类时间线对齐关系：
- HTML 文档下载结束时间 vs
DOMContentLoad时间戳：如果间隔大，说明有同步 JS 阻塞了解析 - CSS 文件下载完成时间 vs “Layout” 首次触发时间：若后者明显滞后，可能是 CSS 文件过大或含 @import 等阻塞操作
- 首屏
img的Start Render时间点：若远晚于该img的下载完成时间，说明它被包裹在未渲染完的父容器里（比如 display: none / visibility: hidden / 未设置宽高导致塌陷）
注意：load 事件时间点基本没参考价值——它等所有图片、iframe 加载完才触发，而用户早在那之前就看到页面了。
为什么优化瀑布流本身不能提升渲染速度
压缩资源、开启 HTTP/2、合并小文件……这些能缩短瀑布流总时长，但对 DOM 渲染起始点几乎没影响。真正卡住渲染的，从来不是“请求发得慢”，而是“请求发得太晚”或“资源来了却不能用”。
典型反模式：
- 把关键 CSS 放在
末尾，导致解析完 HTML 才开始下载，首屏白屏延长 - 用
document.write动态注入 JS，强制浏览器重新扫描整个 HTML 流，打断已有解析进度 - 图片没设
width/height属性，加载前高度为 0，造成布局抖动（layout shift），即使图片早已下载完
瀑布流是诊断工具，不是优化目标。盯着“减少请求数”不如盯住“让关键资源在 HTML 开头就声明”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
