从Timing看HTTP请求的优化方向

1, 背景

在Chrome开发者工具中,有一个Timing菜单,能够查看每个HTTP请求耗时分布,以下浏览器

2, 内容

Queued at 8.4 ms
Started at 8.4 ms

Resource Scheduling    DURATION
Queueing               2.98 ms

Connection Start       DURATION
Stalled                16.94 ms
Proxy negotiation      0.76 ms
DNS Lookup             5.42 ms
Initial connection     16.58 ms
SSL                    10.43 ms

Request/Response       DURATION
Request sent           41 us
Waiting (TTFB)         84.12 ms
Content Download       5.48 ms

(Total:)               132.21 ms

咱们依次从上往下,对照官方文档来看。缓存

2.1 Queued at 8.4ms, 它表示当前的这个请求在这个页面加载过程当中,加入到请求队列中的时间。这个数值是从0开始计算的,而后按照加入队列的顺序,依次累加的。bash

为何会排队呢?由于浏览器对同一时间,同一个Host发起的HTTP1.1并发请求的个数作了限制,不是全部的请求都能发出去,因此须要排队。服务器

个数限制详情以下网络

BrowserVersion | ConnectionsPerHostname | MaxConnections
----------------------------------------------------------
 Chrome34/32    | 6                      | 10
 IE9            | 6                      | 35
 IE10           | 8                      | 17
 IE11           | 13                     | 17
 Firefox27/26   | 6                      | 17
 Safari7.0.1    | 6                      | 17
 Android4       | 6                      | 17
 ChromeMobile18 | 6                      | 16
 IE Mobile9     | 6                      | 60

Note: ConnectionsPerHostname is the maximum number of concurrent http requests that browsers will make to the same domain. To increase the number of concurrent connections, one can host resources (e.g. images) in different domains. However, you cannot exceed MaxConnections, the maximum number of connections a browser will open in total - across all domains.并发

注意: ConnectionsPerHostname是浏览器对同一个域名能发起的http请求的最大并发数量。为了增长这个并发链接数,能够把资源(好比图片)放置到在不一样的域名下。然而,你不能超过 MaxConnections, 这是浏览器对全部的域名能发起的http请求的最大并发数量。app

数据来源: https://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browserdom

本次请求的User-Agent是Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36,http请求链接最大并发数量为6。异步

2.2 Started at 8.4 ms,表示加入到队列以后,实际开始处理的时间。socket

2.3 Resource Scheduling    DURATION
      Queueing                       2.98 ms

资源排期,排队,表示排队等待时间,就是 从添加到待处理队列 到 实际开始处理的 时间间隔。

Queuing
A request being queued indicates that:
The request was postponed by the rendering engine because it’s considered lower priority than critical resources (such as scripts/styles). This often happens with images.
The request was put on hold to wait for an unavailable TCP socket that’s about to free up.
The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1.
Time spent making disk cache entries (typically very quick.)

队列

一个排队中的请求代表:

这个请求被渲染引擎延迟了,由于比起关键的资源(好比脚本/样式),这个请求被当作为低优先级的。这常常发生的图片请求中。

这个请求被hold住,为了等待一个暂不可用的 待释放的TCP套接字。

这个请求被hold住,由于浏览器在HTTP1.0上 只容许 每一个Host 6个 TCP链接。

花费在建立硬盘缓存实体的时间(通常会很是快)。

2.4 Connection Start       DURATION
              Stalled                16.94 ms
     Proxy negotiation      0.76 ms
       DNS Lookup             5.42 ms
       Initial connection     16.58 ms
               SSL                    10.43 ms

链接开始,延迟

Stalled/Blocking
Time the request spent waiting before it could be sent. It can be waiting for any of the reasons described for Queueing. Additionally, this time is inclusive of any time spent in proxy negotiation.

延迟/阻塞

在请求能够被发出去以前的等待时间。它可能在等待哪些用来描述成为排队的理由。此外,这个时间包含了用到代理协商中的时间。通常是代理协商、以及等待可复用的TCP链接释放的时间,不包括DNS查询、创建TCP链接等时间等。

Proxy Negotiation
Time spent negotiating with a proxy server connection.

代理协商

花费在和代理服务器链接的协商上的时间。


DNS Lookup
Time spent performing the DNS lookup. Every new domain on a page requires a full roundtrip to do the DNS lookup.

DNS 查询

花费在DNS查询上的时间。每个页面上的新的域名都须要一个完整的回路来作这个DNS查询。当本地DNS缓存没有的时候,DNS查询的时间多是有一段长度的,可是你一旦在host中设置了DNS,或者第二次访问,因为浏览器的DNS缓存还在,这个时间就为0了。


Initial Connection / Connecting
Time it took to establish a connection, including TCP handshakes/retries and negotiating a SSL.

初始化链接/链接中

花费在创建链接上的时间,包括 TCP握手/重试 和 协商SSL。至关于客户端从发请求开始到TCP握手结束这一段,在数值上,它包括了SSL处理时间。


SSL
Time spent completing a SSL handshake.

花费在完成SSL握手上的时间。

2.5 Request/Response       DURATION
           Request sent           41 us
         Waiting (TTFB)         84.12 ms
     Content Download       5.48 ms


Request Sent / Sending
Time spent issuing the network request. Typically a fraction of a millisecond.

请求已发送 / 发送中

花费在发送网络请求的时间。一般是1毫秒的一小部分。


Waiting (TTFB)
Time spent waiting for the initial response, also known as the Time To First Byte. This time captures the latency of a round trip to the server in addition to the time spent waiting for the server to deliver the response.

等待(TTFB)

花费在等待初始化响应的时间,也常常被称为 Time To First Byte, 从发出请求到第一个字节返回的时间。这个时间获取到的是 从浏览器到服务器 到 服务器处理、返回响应的 一个回路时间,包含网络延迟时间。服务器优化的目的就是要让这个时间段尽量短。


Content Download / Downloading
Time spent receiving the response data.

内容下载/下载中

花费在接收响应数据的时间。收到响应的第一个字节,到接受完最后一个字节的时间,就是下载时间。

 

3,优化

咱们一样从上到下来看

3.1 增大浏览器的Http并发请求数量,减小排队时间,好比升级HTTP1.1 到 SPYD,HTTP2.0,利用这二者的长链接和多路复用技术,减小TCP初始化链接。

3.2 减小延迟/阻塞时间,在服务端减小代理跳转,重定向,在请求中开启 Keep Alive, (临时)关闭SSL,用HTTP代替HTTPS;

3.3 优化进程管理,代码执行层面的优化,缓存,DB,同异步,接口调用等;

相关文章
相关标签/搜索