理解资源的时间线(ChromeDevTool)

Author : lovecicy

实在是好久没有来写博客了,懒了,对技术的追求热情减弱了,也因为最近一直提不起精神来。夜深人静,就想一个人静静,不想发呆,想找点事情做做,别让脑袋闲下来,就找了篇ChromeDevTool的文档翻译一下吧。

如果英文好,可以直接访问这里

理解资源在网络中被收集的各个阶段是非常重要的。这是解决加载问题的基础。

所有的网络请求都被当做资源。当它们从网络上被获取到的时候开始,资源就有了各自的生命周期,我们把这个生命周期叫做资源的时间线。网络面板使用的是与提供给应用开发者相同的资源时间线API。

资源时间线API提供了关于每个资源被接收到的时间线的丰富细节。请求声明周期的主要阶段有:

  • 重定向
    • 立即开始startTime时刻
    • 重定向发生的时候,redirectStart时刻也立即发生
    • 如果重定向发生在这个阶段的最后,那么redirectEnd时刻将会发生
  • App Cache
    • 如果应用缓存填充了请求,那么fetchStart时刻会发生
  • DNS
    • domainLookupStart时刻会在DNS请求开始时发生
    • domainLookupEnd时刻会在DNS请求结束时发生
  • TCP
    • 初始化服务器连接时,会发生connectStart时刻
    • 如果使用了TLS或SSL,那么安全连接的握手开始时,secureConnectionStart时刻将会发生
    • 连接到服务器的连接完成时,connectionEnd时刻将会发生
  • Request
    • 当对某个资源的请求被发送到服务器上时,requestStart时刻就会发生
  • Response
    • 当服务器开始响应请求时,我们定义这个时刻为responseStart时刻
    • 当请求结束,数据被接收到时,我们定义这个时刻为responseEnd时刻

resource-timing-api

DevTools中的视图

有三种方法可以在网络面板中查看一个给定资源的完整时间线信息。

  1. 将鼠标悬停在时间线列的时序图上,会弹出一个弹出框,展示完整的时间线数据。
  2. 点击对应资源,并打开对应资源的Timing tab。
  3. 在JS中使用Timing API来获取原始数据。

resource-timing-data

下面的代码可以在DevTools的console中运行。这里用到了网络时间线API来获取所有资源,然后过滤出资源名中带有“style.css”的资源,如果找到,将会返回。

performance.getEntriesByType('resource')
    .filter(item => item.name.includes("style.css"))

resource-timing-entry

  • Queuing

    如果一个请求在队列中,意味着:

    • 这个请求被渲染引擎推迟了,因为渲染引擎认为它比重要资源的优先级低(比如scripts/styles)。通常者会发生在图片资源上。
    • 这个请求被搁置,等待一个即将被释放的无效TCP socket。
    • 这个请求被搁置,因为在HTTP 1.* 版本中,同一个源只允许同时建立6个TCP连接。
    • 制作硬盘缓存条目的时间(通常非常快)。
  • Stalled/Blocking

    请求等待被发送的时间,可能是Queueing阶段描述的原因中的任何一个原因。另外,这个时间也包括了代理协商阶段的时间。

  • Proxy Negotiation

    与代理服务器连接协商的时间。

  • DNS Lookup

    DNS查找的时间。页面上的每个新域名都需要一次完整的链路往返来完成DNS查找。

  • Initial Connection / Connecting

    建立连接的时间,包括TCP握手/重试和SSL协商。

  • SSL

    完成一次SSL握手的时间。

  • Request Sent / Sending

    发起网络请求的时间,通常不到1ms。

  • Waiting (TTFB)

    等待初始返回的时间,通常也叫做首字节时间(TTFB)。这个时间包括捕捉到一次到服务器的回路的延迟时间,还有等待服务器发送请求的时间。

  • Content Download / Downloading

    接收相应数据的时间。

诊断网络问题

通过网络面板,可以发现很多可能的问题。而想要发现这些问题,需要对客户端和服务器之间的沟通和协议的限制有很好的理解。

排队或阻塞系列

最常见的问题是一系列的请求被排队或阻塞。这意味着向同一个站点请求了太多的资源。在HTTP 1.0/1.1连接中,Chrome最多同时向一个主机发起6个TCP连接。如果你一次性请求12个资源,前6个请求会先发起,后面的6个会被加入等待队列。一旦前6个请求中的一个完成,队列中的第一个请求会被处理。

stalled-request-series

为了解决传统的HTTP 1.*流量问题,你可能需要完成域名分区。也就是设置多个子域名来提供资源服务,然后将资源平均分布到多个子域名下。

修复HTTP 1.连接的方法并不适用于HTTP 2的连接。事实上,正好相反。如果你部署了HTTP 2,不要进行域名分区,也不要将资源分布在子域名下,这违背了HTTP 2的设计。在HTTP 2中,有一个单独的TCP连接来进行多路复用连接。摆脱了HTTP 1.的6个链接限制,多个资源可以在一个连接内同时被传送。

慢TTFB(Slow Time to First Byte)

AKA: 一大片绿色

indicator-of-high-ttfb

慢TTFB可以从大段的等待时间发现。推荐的等待时间是200ms以下。一个很大TTFB值意味着两个主要的问题:

  1. 客户端和服务端的网络状况很差。
  2. 服务端响应慢。

要定位很大的TTFB值问题,首先尽可能排除网络问题。理想的状况是,在本地搭建服务,看是否仍然有很大的TTFB值。如果是,则说明应用的响应速度需要优化。这可能意味着优化数据库查询,增加缓存,修改web服务器的配置。有太多原因导致后端变慢了。你需要研究你的软件来发现到底是什么影响了性能。

如果本地服务下的TTFB值很小,那么客户端和服务器之间的网络就是问题所在。网络穿越可以受很多因素影响。客户端和服务器中间有许多的网络点,每个网络点都有自己的连接限制,这就会引起问题。最简单的检验减少TTFB值的方法就是将你的应用部署在另一个主机下,看看TTFB的值是否有改善。

压缩传输效率(Hitting throughput capacity)

AKA: 一大片蓝色

indicator-of-large-content

如果你发现内容下载阶段花费了大量的时间,那么改进服务器响应或连接并没有什么乱用。首要的解决方法是减少返回的字节数。

standard

Have your say