- 了解资源时序的阶段。
- 知道每个阶段提供给资源计时API。
- 在时间线图中实现性能问题的不同指标。 如系列透明条或大绿色块。
所有网络请求都被视为资源。 当它们通过网络检索时，资源具有以资源定时表示的不同的生命周期。 网络小组使用相同的资源定时API是提供给应用程序开发人员。
资源计时API提供了关于每个单独资产接收时间的详细信息。 请求生命周期的主要阶段是：
- 重定向
- 立即开始
startTime。 - 如果重定向发生，
redirectStart开始为好。 - 如果重定向在这个阶段结束时发生的再
redirectEnd将采取。 - 应用程序缓存
- 如果它是应用程序缓存履行请求，
fetchStart时间服用。 - DNS
domainLookupStart时间被取在DNS请求的开始。domainLookupEnd时间被取在DNS请求的结束。- TCP
connectStart当最初连接到服务器取。- 如果TLS或SSL的使用，则
secureConnectionStart会时握手开始用于固定连接的开始。 connectEnd当到服务器的连接完成拍摄。- 请求
requestStart一旦对资源的请求已被发送到服务器取。- 响应
responseStart是时间时服务器最初响应请求。responseEnd是时候请求结束，数据被检索。
在DevTools中查看
要查看网络面板的给定条目的完整时间信息，您有三个选项。
- 将时间图表悬停在时间轴列下。 这将显示一个弹出窗口，显示完整的时序数据。
- 单击任何条目并打开该条目的“计时”选项卡。
- 使用资源计时API从JavaScript中检索原始数据。
这段代码可以在DevTools控制台中运行。 它将使用网络计时API来检索所有资源。 然后它过滤条目，查找**“style.css”的名称的条目。 如果发现它将被返回。
performance.getEntriesByType('resource').filter(item => item.name.includes("style.css"))
- 排队
- 如果请求排队，则表明：
- 停止/阻塞
- 发送请求之前等待的时间。 它可以等待任何描述的排队的原因。 此外，此时间**在代理协商中花费的任何时间。
- 代理协商
- 与代理服务器连接协商花费的时间。
- DNS查找
- 执行DNS查找所用的时间。 页面上的每个新域都需要完整的往返才能进行DNS查找。
- 初始连接/连接
- 花费的时间建立连接，**TCP握手/重试和谈判中的SSL。
- SSL
- 完成SSL握手所用的时间。
- 请求已发送/正在发送
- 发出网络请求所花费的时间。 通常是几分之一毫秒。
- 等待（TTFB）
- 等待初始响应所花费的时间，也称为到第一个字节的时间。 此时间除了等待服务器传递响应所花费的时间之外，还捕获到服务器的往返行程的延迟。
- 内容下载/下载
- 接收响应数据所花费的时间。
诊断网络问题
通过网络面板可以发现许多可能的问题。 能够找到这些需要对客户端和服务器如何通信以及协议所施加的限制有很好的理解。
排队或失速系列
最常见的问题是一系列排队或停滞的项目。 这表示从单个客户端检索的资源太多。 在HTTP 1.0 / 1.1连接上，Chrome对每个主机最多执行6个TCP连接。 如果您一次请求十二个项目，前六个将开始，后一半将排队。 一旦原始一半完成，队列中的第一个项目将开始其请求过程。
要解决这个问题，传统的HTTP流量1，你需要实现域分片 。 这使得应用程序上的多个子域可以从中提供资源。 然后拆分在子域之间均匀分配的资源。
对于HTTP连接1的修补程序不适用于HTTP连接2。 事实上，它伤害他们。 如果部署了HTTP 2，请不要对资源进行域划分，因为它会影响HTTP 2的工作原理。 在HTTP 2中，存在到充当复用连接的服务器的单个TCP连接。 这消除了HTTP 1的六个连接限制，并且可以通过单个连接同时传输多个资源。
慢时间到第一个字节
AKA：很多绿色
到第一个字节的慢时间（TTFB）被高等待时间识别。 建议你有这样的200ms下 。 高TTFB揭示两个主要问题之一。 或者：
- 客户端和服务器之间的网络状况不佳，或
- 缓慢响应的服务器应用程序
为了解决高TTFB，首先切出尽可能多的网络。 理想情况下，在本地托管应用程序，并查看是否仍有一个大的TTFB。 如果存在，那么应用程序需要针对响应速度进行优化。 这可能意味着优化数据库查询，为内容的某些部分实现缓存或修改Web服务器配置。 后端可能很慢的原因有很多。 您需要对您的软件进行研究，并找出不符合您的效果预算的内容。
如果TTFB本地低，那么您的客户端和服务器之间的网络是问题。 网络遍历可能受到任何数量的事情的阻碍。 在客户端和服务器之间有很多点，每个都有自己的连接限制，可能会导致问题。 测试减少这种情况的最简单的方法是将您的应用程序放在另一台主机上，看看TTFB是否改进。
击中吞吐量
AKA：很多蓝色
如果您在内容下载阶段看到很多时间，那么改进服务器响应或连接将无济于事。 主要的解决方案是发送更少的字节。
