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

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

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

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

由于许多人来到这里调试他们缓慢的网站，我想告诉你我的情况，没有谷歌的解释有助于解决。我的巨大的停滞时间(有时是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年对我来说就可以了。

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

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

这篇文章来自Chome-devtools的官方网站，它很有帮助。 我在这里引用:

Queuing If a request is queued it indicated that: The request was postponed by the rendering engine because it's considered lower priority than critical resources (such as scripts/styles). This often happens with images. The request was put on hold to wait for an unavailable TCP socket that's about to free up. The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1. Time spent making disk cache entries (typically very quick.) Stalled/Blocking Time the request spent waiting before it could be sent. It can be waiting for any of the reasons described for Queueing. Additionally, this time is inclusive of any time spent in proxy negotiation.

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

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