http - 了解Chrome网络日志“停滞不前”
我在chrome中有以下网络日志：
我不明白其中的一件事：填充灰色条和透明灰色条之间的区别是什么。
setec asked 2019-05-26T15:25:19Z
4个解决方案
142 votes
Google在DevTools文档的评估网络性能部分中提供了这些字段的细分。
摘自资源网络时间：
失速/阻塞
请求在发送之前等待的时间。 此时间包括代理协商所花费的任何时间。 此外，这一次将包括当浏览器等待已建立的连接可供重用时，遵守Chrome的每个原始规则最多六个TCP连接。
（如果您忘记了，Chrome在悬停工具提示和“计时”面板下方有一个“解释”链接。）
基本上，您将看到这一点的主要原因是Chrome每次只下载每个服务器6个文件，其他请求将停止，直到连接插槽可用。
这不一定需要修复，但避免陷入停滞状态的一种方法是将文件分布在多个域名和/或服务器上，如果适用于您的需要，请记住CORS，但HTTP2可能是更好的选择 往前走。 资源捆绑（如JS和CSS连接）也可以帮助减少停滞的连接数量。
10 votes
DevTools：[network]解释请求之前的空条
进一步调查并确定我们的停滞和排队范围之间没有显着差异。 都 是从其他时间戳的delta计算的，而不是 从netstack或渲染器提供。
目前，如果我们正在等待套接字可用：
- 如果发生一些代理协商，我们会称之为停滞不前
- 如果不需要代理/ ssl工作，我们将其称为排队。
6 votes
[https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing]
这来自Chome-devtools的官方网站，它有所帮助。在这里我引用：
- 排队 如果请求排队，则表明：
- 请求被渲染引擎推迟，因为它被认为比关键资源（例如脚本/样式）的优先级低。 这通常发生在图像上。
- 请求被暂停以等待即将释放的不可用TCP套接字。
- 请求被暂停，因为浏览器在HTTP 1上每个源只允许六个TCP连接。 制作磁盘缓存条目所花费的时间（通常非常快）。
- 失速/阻塞 请求在发送之前等待的时间。 它可以等待排队描述的任何原因。 此外，此时间包括代理协商所花费的任何时间。
1 votes
我的情况是页面在打开时发送带有不同参数的多个请求。 所以大多数人都“陷入困境”。 立即发送的以下请求变得“停滞”。 避免不必要的请求会更好（懒惰......）。