我的情况是，页面在打开时发送了多个具有不同参数的请求。所以大多数公司都被“拖延”了。随后立即发送的请求会“停滞”。避免不必要的请求会更好(偷懒…)。

我的情况是，页面在打开时发送了多个具有不同参数的请求。所以大多数公司都被“拖延”了。随后立即发送的请求会“停滞”。避免不必要的请求会更好(偷懒…)。

DevTools: [network]解释请求前的空条

进一步调查发现，我们的暂停和排队范围之间没有显著差异。这两个 是根据其他时间戳的增量计算的，而不是 由netstack或renderer提供。 目前，如果我们正在等待一个套接字变得可用: 如果进行了代理谈判，我们就称之为停滞 如果不需要代理/ssl工作，我们将其称为排队。

谷歌在DevTools文档的评估网络性能一节中给出了这些字段的细分。

资源网络定时节选:

停滞/阻塞 请求在发送之前所花费的等待时间。此时间包括代理谈判所花费的时间。此外，这个时间还包括浏览器等待一个已经建立的连接重新使用的时间，遵守Chrome的每个起源规则最多6个TCP连接。

(如果你忘了，Chrome在鼠标悬停的工具提示和“计时”面板下有一个“解释”链接。)

基本上，你会看到这种情况的主要原因是因为Chrome每次只会在每个服务器上下载6个文件，其他请求将会被暂停，直到有可用的连接插槽。

这并不一定需要修复，但是避免停滞状态的一种方法是跨多个域名和/或服务器分发文件，如果适用于您的需求，请记住CORS，但是HTTP2可能是未来更好的选择。资源捆绑(如JS和CSS连接)也有助于减少断开连接的数量。

由于许多人来到这里调试他们缓慢的网站，我想告诉你我的情况，没有谷歌的解释有助于解决。我的巨大的停滞时间(有时是1分钟)是由运行在Windows上的Apache有太少的工作线程来处理连接造成的，因此它们正在排队。

这可能适用于你，如果你的apache日志有以下注意事项:

Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

Apache httpd.conf中已解决此问题。取消: 包括conf /额外的/ httpd-mpm.conf

并编辑httpd-mpm.conf

<IfModule mpm_winnt_module>
   ThreadLimit              2000
   ThreadsPerChild          2000
   MaxConnectionsPerChild   0
</IfModule>

注意，您可能不需要2000个线程，或者可能需要更多线程。2000年对我来说就可以了。

我最近也遇到了请求延迟的问题。如果您已经用尽了其他答案中提到的所有其他修复程序，这可能会有所帮助。

如果你正在为请求使用fetch API，那么你可能还想尝试删除请求选项中的“keep-alive”属性。

这对我来说是一个讨厌的bug，删除这个可以摆脱拖延的问题。