了解Chromenetworking日志“已停止”状态
我有一个以下的networkingloginchrome：
我不明白其中的一点：填充灰色条和透明灰色条之间有什么区别。
Google在DevTools文档的评估networking性能部分中列出了这些字段的细目。
摘自资源networking时间 ：
失速/阻塞
请求等待发送之前等待的时间。 这一次是包含代理谈判花费的时间。 此外，这段时间将包括浏览器何时等待已build立的连接可用于重用，并遵循Chrome每个原始规则的最多六个 TCP连接。
（如果您忘记了，Chrome在hover工具提示和“计时”面板下有一个“解释”链接。）
基本上，你会看到这一点的主要原因是因为Chrome一次只能下载每个服务器6个文件，而其他请求将被阻止，直到连接插槽变为可用。
这不一定是需要修复的东西，但是避免停顿状态的一种方法是将文件分布在多个域名和/或服务器上，如果适用于您的需要，请牢记CORS ，但HTTP2可能是更好的select向前走。 资源绑定（如JS和CSS连接）也可以帮助减less停滞连接的数量。
DevTools：[networking]解释前面请求的空白栏
进一步调查，并确定我们的失速和排队范围之间没有显着差异。 两者都是根据其他时间戳的增量来计算的，而不是从netstack或渲染器提供的。
目前，如果我们正在等待套接字可用：
- 如果发生一些代理协商，我们会把它叫做停滞
- 如果不需要proxy / ssl工作，我们会叫它排队。
这来自Chome-devtools官方网站，它有帮助。 在这里我引用：
- 排队如果请求排队，它表示：
- 该请求被渲染引擎推迟，因为它被认为是比关键资源（如脚本/样式）更低的优先级。 这经常发生在图像上。
- 该请求被搁置，等待一个即将释放的不可用的TCP套接字。
- 该请求被搁置，因为浏览器只允许在HTTP 1上的每个源的六个TCP连接。花在创build磁盘caching条目上的时间（通常非常快）。
- 阻止/阻止请求等待发送之前等待的时间。 它可能正在等待所描述的任何排队原因。 此外，这一次是包含在代理商谈判中花费的时间。
我的情况是，该页面打开时，正在发送不同参数的多个请求。 所以大多数人正在“停滞”。 以下请求立即发送“停滞”。 避免不必要的请求会更好（懒惰…）。
