我在 chrome 中有以下网络登录：
我不明白其中的一件事：填充的灰色条和透明的灰色条有什么区别。
【问题讨论】：
标签： google-chrome http httprequest google-chrome-devtools
Google 在其 DevTools 文档的 Evaluating network performance 部分中对这些字段进行了细分。
停滞/阻塞
请求在发送前等待的时间。该时间包括在代理协商中花费的任何时间。此外，此时间将包括浏览器等待已建立的连接可供重用的时间，遵守 Chrome 的 maximum six TCP 连接每个源规则。
（如果您忘记了，Chrome 在悬停工具提示和“计时”面板下方有一个“说明”链接。）
基本上，您会看到这种情况的主要原因是因为 Chrome 一次只能为每个服务器下载 6 个文件，并且其他请求将被停止，直到连接槽可用为止。
这不一定是需要修复的问题，但避免停滞状态的一种方法是跨多个域名和/或服务器分发文件，如果适用于您的需要，请记住 CORS，但是 HTTP2可能是一个更好的选择。资源捆绑（如 JS 和 CSS 连接）也有助于减少停滞连接的数量。
【讨论】：
file:///C:/...加载页面时不时遇到停滞状态
由于很多人来到这里调试他们缓慢的网站，我想告诉你我的案例，谷歌的解释都没有帮助解决。我的巨大停滞时间（有时 1 分钟）是由于在 Windows 上运行的 Apache 有太少的工作线程来处理连接，因此它们被排队。
如果您的 apache 日志有以下注释，这可能适用于您：
Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting
此问题已在 Apache httpd.conf 中得到解决。取消注释： 包括 conf/extra/httpd-mpm.conf
并编辑 httpd-mpm.conf
<IfModule mpm_winnt_module>
ThreadLimit 2000
ThreadsPerChild 2000
MaxConnectionsPerChild 0
</IfModule>
请注意，您可能不需要 2000 个线程，也可能需要更多。 2000 年对我来说还可以。
【讨论】：
DevTools: [network] explain empty bars preceeding request
进一步调查发现，我们的 Stalled 范围和 Queuing 范围之间没有显着差异。两个都 是根据其他时间戳的增量计算的，而不是 从网络堆栈或渲染器提供。
目前，如果我们正在等待套接字可用：
- 如果发生代理协商，我们会称之为停滞
- 如果不需要代理/SSL 工作，我们将其称为排队。
【讨论】：
我的情况是页面在打开时发送多个具有不同参数的请求。所以大多数都被“停滞”了。立即发送的以下请求被“停止”。避免不必要的请求会更好（懒惰......）。
【讨论】：
这来自 Chome-devtools 的官方网站，它有帮助。 我在这里引用：
- 排队 如果请求排队，则表明：
- 请求被渲染引擎推迟，因为它的优先级低于关键资源（例如脚本/样式）。这通常发生在图片上。
- 请求被搁置以等待即将释放的不可用 TCP 套接字。
- 请求被搁置，因为浏览器仅允许 HTTP 1 上每个源的六个 TCP 连接。 制作磁盘缓存条目所花费的时间（通常非常快）。
- 停滞/阻止 请求在发送之前等待的时间。它可能正在等待队列中描述的任何原因。此外，此时间包括在代理协商中花费的任何时间。
【讨论】：