4、瀑布图基础：瀑布图的构成要素
说到性能诊断，我最先打开的永远不是代码，而是瀑布图。说白了，瀑布图就是浏览器把每个网络请求的“一生”都画在了时间线上。你一眼就能看出来——哪个请求慢，慢在哪一阶段。
我把瀑布图拆成几个核心部分来讲。每一个部分，我都踩过坑。
4.1 请求时间线——一条请求的“体检报告”
浏览器发起一个请求，其实经历了多个阶段。瀑布图把每个阶段都画成一段横条。横条越长，说明这个阶段耗时越多。
- 队列/阻塞（Queuing / Blocked）：请求在排队等待，还没发出
- DNS 查找：把域名解析成 IP
- TCP 连接：三次握手
- TLS 协商：HTTPS 的加密握手
- 请求发送：你的数据从客户端到服务器
- 等待（TTFB）：从发出请求到收到第一个字节
- 内容下载：接收服务器返回的数据
我个人的习惯是，先看总时长，再看每个阶段的颜色分布。如果某个请求的「等待」阶段特别长，我基本就能判断是后端慢了。如果「内容下载」长，那可能是资源太大或网络太慢。
4.2 排队与阻塞——请求也会“堵车”
你可能会问：为什么明明网速很快，请求就是发不出去？
嗯，这里要注意。浏览器对同一个域名有连接数限制。HTTP/1.1 下，Chrome 限制每个域名最多 6 个并发连接。多余的请求就得排队。
在瀑布图中，如果请求的最左侧有一段浅色区域（通常是灰色或浅蓝色），鼠标悬停显示“Queuing”或“Stalled”，说明你的请求在排队。我曾经遇到过，一个页面 100 多个请求全部排在一个域名下，光是排队就浪费了 2 秒。
解决办法也直接：
- 域名分片（Domain Sharding）——把资源分散到多个域名
- 升级到 HTTP/2——多路复用，一个连接可以同时发多个请求
- 合并资源——减少请求数量
4.3 DNS 查询与 TCP 连接
这两个阶段通常很快，但如果慢起来，也很要命。
DNS 查询：你想想看，每次输入网址，浏览器都要问 DNS 服务器：“这个域名对应的 IP 是多少？”如果 DNS 服务器响应慢，或者你用的 DNS 服务本身不稳定，这个阶段就会拉长。
我在项目中遇到过，某次线上排查，发现主页资源下载都好，就是首屏慢了 1 秒。后来一看瀑布图，DNS 查询花了 800ms。最后发现是公司内部 DNS 配置出了问题。
TCP 连接：三次握手本身很快，但如果物理距离远、丢包率高，每次握手都会延迟。别小看这几十毫秒，累积起来就多了。
| 阶段 | 正常耗时 | 需要警惕的耗时 |
|---|---|---|
| DNS 查询 | < 50ms | > 200ms |
| TCP 连接 | < 30ms | > 100ms |
| TLS 握手 | < 100ms | > 300ms |
4.4 TTFB——最重要的“后端测速仪”
TTFB（Time To First Byte），就是从客户端发出请求，到收到服务器返回的第一个字节所花费的时间。我个人最关注这个指标，因为它直接反映了后端性能。
瀑布图里，TTFB 通常就是那段较长的深色横条。如果它超过 500ms，我基本断定后端是瓶颈。
TTFB 包含哪些时间？
- 网络传输延时（你到服务器的 RTT）
- 服务器处理时间（CPU 计算、数据库查询等）
- 后端框架的启动/路由开销
优化一个后台管理系统，后端用了 Node.js，每次请求 TTFB 都在 800ms 左右。查了半天，发现是每次请求都要重新建立数据库连接池。
改成连接池复用后，TTFB 直接降到 120ms。所以 TTFB 高，不一定是服务器慢，也可能是配置不合理。
4.5 内容下载阶段
最后一段就是实际接收数据了。这个阶段主要看两点：
- 资源大小：JS 文件 5MB 的话，就算网速再好也要下载一会儿
- 网络速度：移动端 3G 下，下载 1MB 可能要 2-3 秒
但有时候你会发现，明明资源不大，下载时间却很慢。为什么？可能是因为网络抖动，或者服务器响应慢导致“下载窗口”没有及时开大。
我见过很多“优化完”的页面，TTFB 只有 200ms，但下载时间却花了 3 秒。一查，资源没压缩、没启用 gzip。说白了，后端再快，前端不给力也是白搭。
到这里，瀑布图的每个构成要素应该都清楚了。下次打开 DevTools 的 Network 面板，你可以先看看每个请求的这几个阶段，找到最长的那个横条，那就是你的突破口。