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

Question

我正在研究chrome dev tools#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为客户端解析从服务器获取其余内容的总时间.除非您正在下载大文件,否则这应该很短.你应该看看文件的大小,网络的条件,然后判断这应该花多长时间.