专注于
IT技术和业内交流

Chrome DevTools — 了解资源加载时序

理解资源下载过程才能解决网页加载慢的问题。

我们可以将所有的网络请求当作资源,当通过网络获取这些资源时,分为不同的生命周期。
Network面板使用的Resource Timing API 和提供给开发者的API是一样的.

Resource Timing API提供了很详细的时间信息。网络请求的生命周期分为以下几个阶段:

  • Redirect
    • 立即开始startTime.
    • 如果一个重定向发生, redirectStart也会开始计时.
    • 重定向结束redirectEnd会记录结束时间.
  • App Cache
    • 如果浏览器有缓存,fetchStart会记录这个时间.
  • DNS
    • domainLookupStart记录DNS请求开始的时间.
    • domainLookupEnd 记录DNS请求结束的时间.
  • TCP
    • connectStart记录开始连接到服务器的时间.
    • 如果用了TLS或SSL,secureConnectionStart记录开始连接时间.
    • connectEnd记录连接完毕时间.
  • Request
    • requestStart记录请求发送到服务器的时间.
  • Response
    • responseStart记录最开始的响应时间.
    • responseEnd记录响应结束时间.

Resource Timing API diagram

在DevTools里查看

在Network面板有3种方法可查看时间信息。

  1. 将鼠标移动到timeline列下的图片上会有一个弹出框展示时间信息数据.
  2. 点击请求列表中的任意一行请求,再点击它的Timing tab.
  3. 在控制台用Resource Timing API获取时间信息.

Resource Timing Information

在控制台中运行下面的代码,它会过滤出资源名字中包含”style.css”的请求

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

Resource Timing Entry

  1. Queuing
    如果一个请求被放入队列中说明:
    * 这个请求因为优先级低而被延后了,比如图片就经常这样。
    * 这个请求被推迟,因为在等待一个即将被释放的不可用的TCP socket。
    * 这个请求被推迟,因为浏览器限制在一个源上只能有6个TCP连接 .
    * 正在生成缓存请求

  2. Stalled/Blocking
    请求发送前的等待时间。请求可能因为进入队列的任意原因而被阻塞。这个时间包括代理协商时间。

  3. Proxy Negotiation
    与代理服务器协商的时间

  4. DNS Lookup
    DNS查询时间。每个新域名都需要一个DNS查询时间。

  5. Initial Connection / Connecting
    建立连接的时间, 包括 TCP 握手或重试和协商SSL.

  6. SSL
    SSL握手时间。

  7. Request Sent / Sending
    请求发送时间,一般几毫秒。

  8. Waiting (TTFB)
    等待响应的时间,即Time To First Byte。这个时间记录了响应延迟时间和服务器发送数据的时间。

  9. Content Download / Downloading
    接收响应数据的时间

诊断网络问题

有很多问题都没有被Network面板覆盖,了解客户端和服务器怎样通信的以及通信协议的限制就可以发现这些问题。

Queued or Stalled series

最常见的问题是很多个请求被阻塞, 这表明有太多的资源是从同一个源抓取。Chrome实现的HTTP 1.0/1.1限制同时只能有6个连接到同一个域名。
如果同时发出12个请求,chrome会先发出6个请求,直到其中一个请求被回复,再从队列中取出一个请求发出去。

Stalled series of requests

为了解决HTTP1的这个问题,你需要实现 domain sharding,即用多个子域名提供服务。

如果你的服务器部署的是HTTP2就不能这么干,因为HTTP2的TCP连接是多路复用的,多个资源可通过同一个连接同时获取。

Slow Time to First Byte

AKA: lots of green

High TTFB Indicator

TTFB就是等待第一个响应字节的时间,最好在200ms以下,以下情况可能会导致高TTFB:

  1. 服务器和客户端之间的网络条件很差, 或者
  2. 服务器端程序响应很慢

为了确定是什么原因导致高TTFB的,首先尽量去除网络连接。
最理想的状态是将应用程序部署在本地看TTFB是否仍然很高。如果是,则你需要优化程序以提高响应速度。
优化包括优化数据库查询, 缓存部分内容,修改服务器配置,优化后端程序等等。

如果部署在本地后,TTFB很低,则网络问题才是主要原因。
网络传输可能被很多种事情干扰。换一台服务器也许会好点^_^。

降低吞吐量

也叫作: 很多蓝色

Throughput capacity Indicator

如果你发现在Content Download阶段花了很多时间,而提高服务响应速度、并行下载等优化措施帮助都不大,这时您需要的是降低你的每次发送的数据量。

本文由向波翻译、周海欧校验,感谢大家的参与.如有错译、漏译请留言我们会及时更正。

未经允许,不得转载本站任何文章:代码山 » Chrome DevTools — 了解资源加载时序

分享到:更多 ()

专注品牌化高端网站建设

商务服务联系我们