了解Chromenetworking日志“已停止”状态

我有一个以下的networkingloginchrome:

网络日志

我不明白其中的一点:填充灰色条和透明灰色条之间有什么区别。

Google在DevTools文档的评估networking性能部分中列出了这些字段的细目。

摘自资源networking时间 :

失速/阻塞

请求等待发送之前等待的时间。 这一次是包含代理谈判花费的时间。 此外,这段时间将包括浏览器何时等待已build立的连接可用于重用,并遵循Chrome每个原始规则的最多六个 TCP连接。

(如果您忘记了,Chrome在hover工具提示和“计时”面板下有一个“解释”链接。)

基本上,你会看到这一点的主要原因是因为Chrome一次只能下载每个服务器6个文件,而其他请求将被阻止,直到连接插槽变为可用。

这不一定是需要修复的东西,但是避免停顿状态的一种方法是将文件分布在多个域名和/或服务器上,如果适用于您的需要,请牢记CORS ,但HTTP2可能是更好的select向前走。 资源绑定(如JS和CSS连接)也可以帮助减less停滞连接的数量。

DevTools:[networking]解释前面请求的空白栏

进一步调查,并确定我们的失速和排队范围之间没有显着差异。 两者都是根据其他时间戳的增量来计算的,而不是从netstack或渲染器提供的。


目前,如果我们正在等待套接字可用:

  • 如果发生一些代理协商,我们会把它叫做停滞
  • 如果不需要proxy / ssl工作,我们会叫它排队。

https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing

这来自Chome-devtools官方网站,它有帮助。 在这里我引用:

  • 排队如果请求排队,它表示:
    • 该请求被渲染引擎推迟,因为它被认为是比关键资源(如脚本/样式)更低的优先级。 这经常发生在图像上。
    • 该请求被搁置,等待一个即将释放的不可用的TCP套接字。
    • 该请求被搁置,因为浏览器只允许在HTTP 1上的每个源的六个TCP连接。花在创build磁盘caching条目上的时间(通常非常快)。
  • 阻止/阻止请求等待发送之前等待的时间。 它可能正在等待所描述的任何排队原因。 此外,这一次是包含在代理商谈判中花费的时间。

我的情况是,该页面打开时,正在发送不同参数的多个请求。 所以大多数人正在“停滞”。 以下请求立即发送“停滞”。 避免不必要的请求会更好(懒惰…)。