速查在线工具箱浏览器瀑布图里每一段到底在等谁？
排队、连接、等待首字节、下载内容，四段各有各的责任方。把等待首字节当成网速慢，就会一直优化错的东西。
直接答案
一次请求在瀑布图里被切成几段，每段对应一个明确的责任方：排队等的是浏览器允许发请求的名额，连接等的是握手，等待首字节等的是服务端处理加一个网络往返，下载等的是把内容传完。
最常见的误判是把整条长度当成网速问题。实际上「等待首字节」通常占总时长的大头，这一段的瓶颈在服务端响应或链路往返，加带宽没有用。
第二常见的误判是忽略排队。同一域名下的并发连接数有限，前面的请求没结束，后面的只能在队列里等着，表现为一大片起始时间靠后的短条。
性能优化最容易变成体力活：把能压的都压了，页面还是慢。问题往往不在体积，而在没看清时间花在哪一段。
这一篇按瀑布图的四段逐段讲责任方，再给出两个能立刻上手的判断方法。
1四段各自的含义与责任方
每一段变长，要动的地方完全不同。
| 分段 | 在等什么 | 常见原因 |
|---|---|---|
| 排队与阻塞 | 等浏览器放出并发名额 | 同域请求过多、被前面的请求占满 |
| 连接与握手 | 建立传输通道 | 新建连接、加密握手、跨域预检 |
| 等待首字节 | 服务端处理加一个往返 | 后端慢、数据库慢、链路往返长 |
| 内容下载 | 把响应体传完 | 资源体积大、带宽受限 |
同一份报表里，只有最后一段与资源体积直接相关，其余三段压缩文件都救不了。
2两种一眼能认出的形态
形态比数字更好认，先看形状再对数字。
| 形态 | 特征 | 先做什么 |
|---|---|---|
| 大片短条起始时间靠后 | 前几秒几乎没请求发出 | 减少同域请求数、提前发起关键请求 |
| 每一条都有一段等长的空白前缀 | 所有请求的首字节都很长 | 查后端响应与链路往返，不要压体积 |
| 个别请求特别长 | 其余正常 | 单独排查该接口或该第三方域名 |
| 长条集中在末尾 | 首屏之后仍在加载 | 把非关键资源延后或按需加载 |
把所有请求都压一遍，通常只影响第三列，前两列的收益往往更大。
3三个立即可用的判断
不需要复杂工具，打开面板就能做。
- 按域名分组看请求数
- 同一域名下并发上限很小，请求越多排队越明显
- 对比首字节与内容下载
- 首字节远大于下载，说明瓶颈在服务端；反过来才是体积问题
- 看有没有重复请求
- 同一资源被加载两次，多半是地址或跨域属性不一致导致缓存不命中
- 压缩资源不会缩短握手
- 连接与握手的时间开销与体积无关，减小文件对这一段没有帮助
优化前先给四段各自拍一个时间戳，改完再对比，才能知道改动有没有落到该落的地方。
相关疑问
首字节很长但文件很小，该怎么优化？
瓶颈不在体积。去查服务端处理时间与链路往返，压缩这个文件不会有明显效果。
为什么很多请求挤在后面才开始？
多半是同一域名的并发连接被占满，前面的请求没结束，后面的只能排队。
下载很慢是不是带宽不够？
先看这一段在总时长里占多大比例。多数页面里它并不是主要瓶颈。
同一资源出现两条记录正常吗？
不正常。常见原因是请求属性不一致导致无法复用缓存，或代码里重复引入了两次。
继续看：相关问题与资料
全部问题解答 →
内容标识：本页内容由人工智能辅助生成，并经人工核对与编辑。详见 人工智能生成内容标识说明。
内容说明：本页针对具体使用问题作答，方法步骤与数值由本站自行整理与复算，事实性内容以对应官方规范与文档为准。内容最后核对日期：2026-10-12。若发现错误，欢迎通过页脚反馈入口告知。
内容说明：本页针对具体使用问题作答，方法步骤与数值由本站自行整理与复算，事实性内容以对应官方规范与文档为准。内容最后核对日期：2026-10-12。若发现错误，欢迎通过页脚反馈入口告知。