Google chrome Chrome网络计时的真正含义是什么？什么会影响每个计时长度？

我正在研究chrome开发工具，以检测必须改进的请求。在之前的链接中，对每个时间都有一个定义，但我不明白在幕后采取了哪些过程会影响时间的长度

下面是3张不同的图片，这是我对发生的事情的理解，如果我错了，请纠正我

暂停：为什么会有这样的计时：请求暂停1.17秒，而其他请求暂停的时间更少

已发送请求：这是我们的请求到达服务器所用的时间

TTFB：服务器用第一个字节的数据做出响应所用的时间

内容下载：整个响应到达客户端之前的时间

---

谢谢

网络是一个变化很大的领域。有很多不同的数字与这些有关，它们在不同的地点之间变化，甚至同一地点有不同类型的内容

以下是您需要更多了解的领域的更多细节：

暂停：这取决于网络堆栈中的其他情况。一件事情根本无法暂停，而其他请求可能会暂停，因为到同一位置的6个连接已经打开。失速的原因有很多，但是最大连接限制是解释为什么会发生失速的一种简单方法

暂停状态意味着，我们现在无法发送请求，因为它需要等待某个原因。一般来说，这没什么大不了的。如果您经常看到它，并且您不在HTTP2协议上，那么您应该考虑最小化从给定位置提取的资源数量。如果您使用的是HTTP2，那么不要太担心这个问题，因为它以不同的方式处理大量请求

环顾四周，看看有多少请求将发送到单个域。可以使用“过滤器”框修剪视图。如果有许多请求发送到同一个域，那么这很可能达到连接限制。域分片是HTTP 1.1处理此问题的一种方法，但在HTTP 2中，它是一种反模式，会影响性能

如果您没有达到最大连接限制，那么问题就更加微妙，需要更实际的调试方法来了解发生了什么

已发送请求：这不是到达服务器的时间，而是到达第一个字节的时间。所有已发送的请求意味着已发送请求，并且网络堆栈花费了X个时间来执行该请求

您不能做任何事情来加快这一速度，它更多的是用于信息和内部调试目的

到第一个字节的时间（TTFB）：这是发送的请求到达目的地，然后目的地处理请求，最后响应穿越网络返回客户端的总时间

高TTFB揭示了两个问题之一。第一个问题是客户端和服务器之间的网络连接不好。因此，数据到达服务器并返回的速度很慢。第二个原因是服务器处理请求的速度慢。这可能是因为硬件薄弱或应用程序运行缓慢。或者，这两个问题可能同时存在

要解决高TTFB问题，首先应尽可能切断网络。理想情况下，将应用程序本地托管在一个低资源虚拟机上，并查看是否仍然存在一个较大的TTFB。如果存在，则需要针对响应速度对应用程序进行优化。如果TTFB在本地超低，那么客户端和服务器之间的网络就是问题所在。有各种各样的方法来处理这个问题，我将不涉及，因为它本身就是一个专业领域。研究网络优化，甚至尝试移动主机，看看您的服务器提供商网络是否存在问题

记住，整个服务器堆栈在这里起作用。因此，如果nginx或apache配置不当，或者数据库需要很长时间才能响应，或者缓存出现问题，那么这些都可能导致延迟。它们也很难在本地检测到，因为本地服务器的配置可能与远程堆栈不同

---

内容下载：这是客户端从TTFB解析到从服务器获取其余内容的总时间。除非下载的是大文件，否则这应该很短。您应该查看文件大小、网络状况，然后判断这需要多长时间。

此处提供了有关所有计时的更多详细信息：此处简化了排队：