Chrome网络时间表的真正含义是什么？每个时间长度会影响什么？ [英] What does Chrome Network Timings really mean and what does affects each timing length?
问题描述
我正在查看chrome开发工具＃资源网络时间
a>来检测必须改进的请求。在之前的链接中，每个时间点都有一个定义，但我不明白在影响期间长度的情况下正在采取什么流程。以下是3种不同的图像，这里是我对发生了什么事情的理解，如果我错了，请纠正我。
停滞：为什么有计时请求的停顿时间为1.17s，而其他人则少了？
发送的请求：我们的请求到达服务器的时间
TTFB ：直到服务器响应数据的第一个字节为止的时间 内容下载：直到整个响应到达客户端
谢谢
网络是一个东西差别很大的领域。有很多不同的数字与这些发挥作用，他们在不同的位置，甚至不同地点与不同类型的内容不同。
这里有一些更详细的信息在你需要更多理解的领域：
停滞：这取决于网络堆栈中还在发生什么。有一件事情根本无法阻止，而其他请求可能会被阻止，因为到同一位置的6个连接已经打开。还有更多的原因是拖延，但最大的连接限制是解释它为什么会发生的简单方法。
停滞状态意味着，我们不能发送现在请求它需要等待某种原因。一般来说，这不是什么大问题。如果您在HTTP2协议中看到了很多并且 ，那么您应该考虑最大限度地减少从给定位置拉出的资源数量。如果您使用的是HTTP2，那么请不要担心太多，因为它会以不同的方式处理大量请求。
环顾四周，看看有多少请求会发送到单个域。您可以使用过滤器框来裁剪视图。如果您有很多请求会进入同一个域，那么这很可能会达到连接限制。 域分片是用HTTP 1.1处理这个问题的一种方法，但是对于HTTP 2它是一种反模式并且会损害性能。
如果你没有达到最大连接限制，那么问题就更加细微，需要更多的实践调试方法来弄清楚发生了什么。
请求发送：这不是到达服务器的时间，即到第一个字节的时间。发送的所有请求的意思是请求被发送，并且它花费了网络堆栈X时间来执行它。
无法为加快速度提高速度，它更适合于信息和内部调试目的。
第一个字节的时间（TTFB）：这是发送请求到达目的地的总时间，然后让目的地处理请求，最后让响应遍历网络回到客户端。
高TTFB揭示了两个问题之一。首先是客户端和服务器之间的网络连接不好。所以数据到达服务器的速度很慢，然后回来。第二个原因是服务器处理请求的速度很慢。这可能是因为硬件太弱或应用程序运行缓慢。或者，这些问题都可以一次存在。
为了解决高TTFB问题，首先要尽可能多地切断网络。理想情况下，在低资源虚拟机上本地托管应用程序，并查看是否仍有大的TTFB。如果有，则应用程序需要针对响应速度进行优化。如果TTFB在本地超低，那么客户端和服务器之间的网络就成了问题。有很多方法可以解决这个问题，我不会介入，因为它本身就是一个专业领域。研究网络优化，甚至尝试移动主机，看看你的服务器提供商网络是否是问题。
请记住整个服务器堆栈在这里发挥作用。因此，如果nginx或apache配置不佳，或者数据库需要很长时间才能响应，或者缓存有问题，那么这可能会导致延迟。由于您的本地服务器在配置上可能与远程堆栈有所不同，因此它们在本地很难检测到。 下载内容：从TTFB解析客户端的时间以从服务器获取其余内容。除非您下载大文件，否则这应该很短。你应该看看文件的大小，网络的条件，然后判断应该花多长时间。
I was looking at chrome dev tools #resource network timing to detect requests that must be improved. In the link before there's a definition for each timing but I don't understand what processes are being taken behind the scenes that are affecting the length of the period.
Below are 3 different images and here is my understanding of what's going on, please correct me if I'm wrong.
Stalled: Why there are timings where the request get's stalled for 1.17s while others are taking less?
Request Sent: it's the time that our request took to reach server
TTFB: Time took until the server responds with the first byte of data
Content Download: The time until the whole response reaches the client
Thanks
Network is an area where things will vary greatly. There are a lot of different numbers that go into play with these and they vary between different locations and even the same location with different types of content.
Here is some more detail on the areas you need more understanding with:
Stalled: This depends on what else is going on in the network stack. One thing could not be stalled at all, while other requests could be stalled because 6 connections to the same location are already open. There are more reasons for stalling, but the maximum connection limit is an easy way to explain why it may occur.
The stalled state means, we just can't send the request right now it needs to wait for some reason. Generally, this isn't a big deal. If you see it a lot and you are not on the HTTP2 protocol, then you should look into minimizing the number of resources being pulled from a given location. If you are on HTTP2, then don't worry too much about this since it deals with numerous requests differently.
Look around and see how many requests are going to a single domain. You can use the filter box to trim down the view. If you have a lot of requests going off to the same domain, then that is most likely hitting the connection limit. Domain sharding is one method to handle this with HTTP 1.1, but with HTTP 2 it is an anti-pattern and hurts performance.
If you are not hitting the max connection limit, then the problem is more nuanced and needs a more hands-on debugging approach to figure out what is going on.
Request sent: This is not the time to reach the server, that is the Time To First Byte. All request sent means is the request is sent and it took the network stack X time to carry it out.
Nothing you can do to speed this up, it is more for informational and internal debugging purposes.
Time to First Byte (TTFB): This is the total time for the sent request to get to the destination, then for the destination to process the request, and finally for the response to traverse the networks back to the client.
A high TTFB reveals one of two issues. The first is a bad network connection between the client and server. So data is slow to reach the server and get back. The second cause is, a slow server processing the request. This is either because the hardware is weak or the application running is slow. Or, both of these problems can exist at once.
To address a high TTFB, first cut out as much network as possible. Ideally, host the application locally on a low-resource virtual machine and see if there is still a big TTFB. If there is, then the application needs to be optimized for response speed. If the TTFB is super-low locally, then the networks between your client and the server are the problem. There are various ways to handle this that I won't get into since it is an area of expertise unto itself. Research network optimization, and even try moving hosts and seeing if your server providers network is the issue.
Remember the entire server-stack comes into play here. So if nginx or apache are configured poorly, or your database is taking a long time to respond, or your cache is having trouble, then these can cause delays. They are also difficult to detect locally, since your local server could vary in configuration from the remote stack.
Content Download: This is the total time from the TTFB resolving for the client to get the rest of the content from the server. This should be short unless you are downloading a large file. You should take a look at the size of the file, the conditions of the network, and then judge about how long this should take.
这篇关于Chrome网络时间表的真正含义是什么？每个时间长度会影响什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
