Chrome网络计时真正意味着什么？每个计时长度有什么影响？

Question

我在查看chrome dev工具＃resource network timing来检测必须改进的请求。在之前的链接中，每个时间都有一个定义，但我不了解影响时间长度的幕后正在采取的过程。

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

停滞不前：为什么有时间请求会在1.17秒停止，而其他人的收费会减少？

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

TTFB ：服务器响应数据的第一个字节所花费的时间

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

由于

Answer 1

网络是一个变化很大的领域。有很多不同的数字可以用于这些，它们在不同的位置之间变化，甚至在不同类型的内容的相同位置。

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

停滞：这取决于网络堆栈中还有其他内容。有一件事情根本无法停滞，而其他请求可能会停滞，因为同一位置的6个连接已经打开。拖延有更多原因，但最大连接限制是解释可能发生的原因的简单方法。

停滞状态意味着，我们现在无法发送请求需要等待某些原因。一般来说，这不是什么大问题。如果你看到很多并且你在HTTP2协议上不，那么你应该考虑尽量减少从给定位置提取的资源数量。如果您使用的是HTTP2，那么请不要过于担心，因为它会以不同的方式处理大量请求。

环顾四周，查看有多少请求转到单个域。您可以使用过滤器框来修剪视图。如果您有很多请求转到同一个域，那么很可能达到连接限制。 域分片是使用HTTP 1.1处理此问题的一种方法，但对于HTTP 2，它是一种反模式并且会损害性能。

如果你没有达到最大连接限制，那么问题会更加细微，需要更多的动手调试方法来弄清楚发生了什么。

发送请求：这不是到达服务器的时间，即时间到第一个字节。发送请求的所有请求都是请求被发送，并且网络堆栈X需要时间来执行它。

没有什么可以做的，以加快速度，更多的是用于信息和内部调试目的。

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

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

要解决高TTFB问题，首先要尽量减少网络数量。理想情况下，在低资源虚拟机上本地托管应用程序，看看是否还有一个大的TTFB。如果有，则需要针对响应速度优化应用程序。如果TTFB本地超低，那么客户端和服务器之间的网络就成了问题。有很多方法可以解决这个问题，因为它本身就是一个专业领域。研究网络优化，甚至尝试移动主机并查看您的服务器提供商网络是否是问题。

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

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