我正在研究chrome dev工具#resource network timing来检测必须改进的请求。在链接之前，每个时间都有一个定义，但我不明白在影响时间长度的幕后采取了什么过程。
下面是3个不同的图像，这是我对正在发生的事情的理解，如果我错了，请纠正我。
停滞不前：为什么有时候请求会在1.17秒停止，而其他请求则减少？
发送请求：这是我们的请求到达服务器的时间
TTFB：服务器以第一个数据字节响应的时间
内容下载：整个响应到达客户端的时间
谢谢
网络是一个变化很大的领域。有许多不同的数字可以与这些数字发挥作用，它们在不同的位置之间变化，甚至在不同类型的内容的相同位置。
以下是您需要更多理解的领域的更多细节：
停滞：这取决于网络堆栈中发生了什么。有一件事情根本无法停滞，而其他请求可能会停滞，因为同一位置的6个连接已经打开。停止的原因更多，但最大连接限制是解释可能发生的原因的简单方法。
停滞状态意味着，我们现在无法发送请求它需要等待某些原因。一般来说，这不是什么大问题。如果您看到很多并且您没有使用HTTP2协议，那么您应该考虑尽量减少从给定位置提取的资源数量。如果您使用的是HTTP2，那么请不要过于担心，因为它会以不同的方式处理大量请求。
环顾四周，查看单个域的请求数量。您可以使用过滤器框来修剪视图。如果您有很多请求转到同一个域，那么很可能达到连接限制。域分片是使用HTTP 1.1处理此问题的一种方法，但对于HTTP 2，它是一种反模式并且会损害性能。
如果你没有达到最大连接限制，那么问题会更加细微，需要更多动手调试方法来弄清楚发生了什么。
发送请求：这不是到达服务器的时间，即时间到第一个字节。发送请求的所有请求都是请求被发送，并且网络堆栈X花费时间来执行它。
没有什么可以做到加快速度，更多的是用于信息和内部调试目的。
第一个字节的时间（TTFB）：这是发送请求到达目的地的总时间，然后是目标处理请求的总时间，最后是响应以将网络传回客户端。
高TTFB揭示了两个问题之一。第一个是客户端和服务器之间的网络连接不良。因此数据很慢到达服务器并返回。第二个原因是，处理请求的服务器速度慢。这可能是因为硬件很弱或应用程序运行缓慢。或者，这两个问题都可以同时存在。
为了解决高TTFB问题，首先要切断尽可能多的网络。理想情况下，在低资源虚拟机上本地托管应用程序，看看是否还有一个大的TTFB。如果有，则需要针对响应速度优化应用程序。如果TTFB本地超低，那么客户端和服务器之间的网络就成了问题。有很多方法可以解决这个问题，因为它本身就是一个专业领域。研究网络优化，甚至尝试移动主机，看看您的服务器提供商网络是否是问题。
请记住，整个服务器堆栈在这里发挥作用。因此，如果nginx或apache配置不当，或者您的数据库需要很长时间才能响应，或者您的缓存遇到问题，那么这些都可能导致延迟。它们也很难在本地检测，因为本地服务器的配置可能与远程堆栈不同。
内容下载：这是TTFB为客户端解析从服务器获取其余内容的总时间。除非您正在下载大文件，否则这应该很短。你应该看看文件的大小，网络的条件，然后判断这应该花多长时间。