Chrome DevTools性能洞察中processing time的含义及异常行为解析

核心定义 #

这里的processing time是Chrome浏览器在发起网络请求前的内部排队与预处理阶段，属于请求调度的前置环节。它未在Network面板中显示，是因为两个面板的计时维度存在差异：

• Network面板从请求实际发送到服务器开始计时，仅展示request sent、waiting、download这些与服务器交互的阶段；
• Performance Insights则从浏览器任务队列中调度该网络请求的时刻开始计时，包含了请求发起前的内部等待时间。

对应你观察到的行为原因 #

1. 并行请求越多，processing time占比越高
   Chrome对同一域名的并行请求数量有默认限制（HTTP/1.1下通常为6个），当页面发起的请求数超过这个阈值时，超出的请求会进入浏览器内部的请求队列等待，直到已有请求释放连接池资源。这种排队等待的时间会被计入processing time，因此并行请求密集的页面中该阶段占比会显著提升；而请求量少的页面无需排队，该阶段占比自然更小。

2. 仅Performance Insights展示该阶段
   如前所述，Network面板的计时起点是请求实际发出的时刻，而processing time是请求被调度但尚未实际发送的前置等待时间，不属于与服务器交互的环节，因此不会在Network面板中显示。

3. processing time由左侧细线标识
   在Performance Insights的网络图表中，左侧的细线代表从浏览器调度该请求任务，到请求实际开始发送的时间区间——也就是内部排队/预处理的阶段，对应你看到的processing time。

4. 所有细线几乎同时结束
   这是因为Chrome的连接池释放后，会批量调度队列中等待的请求。当之前的一批请求完成了waiting或download阶段、释放了连接资源，浏览器会一次性将排队的请求批量发起，因此这些请求的processing time会在同一毫秒结束，同步进入request sent阶段。

内容的提问来源于stack exchange，提问作者Ofer Molad