前言
如果我们发现自己页面加载慢,通常会打开DevTools
的Network
栏找到具体的慢的请求,那他到底慢在哪呢?
Timing包含的内容
- Queuing
- Stalled/Blocking
- Proxy Negotiation
- DNS Lookup
- Initial Connection / Connecting
- SSL
- Request Sent / Sending
- Waiting (TTFB)
- Content Download / Downloading
1、Queuing
主要是资源加载的排队
-
不可优化部分
- 请求被渲染引擎推迟,如脚本/样式会
优先
,图片推迟
。 - 生成磁盘缓存条目所用的时间(通常非常迅速)。
- 请求被渲染引擎推迟,如脚本/样式会
-
可优化部分
-
请求已被暂停,以等待将要释放的不可用
TCP
套接字。浏览器线程池不是无限的,需要等待socket(TCP)释放。 合并小文件减少请求。
-
请求被暂停,
HTTP 1
上,浏览器仅允许每个源
拥有六个TCP
连接。主要是对服务器的保护。 可以把资源放到不同的域名上,参考`域名发散`。
-
2、Stalled/Blocking
请求等待发送所用的时间。Queuing
中的所有原因加上代理协商所用的任何时间。
-
不可优化部分
-
Queuing
中不可优化部分 - 代理协商
-
-
可优化部分
-
Queuing
中可优化部分 - 相同的N次请求 缓存锁,一般资源加载不会加载相同的,但
ajax
有可能,加timestamp
可解决。
-
注意1:
Stalled
是Queuing
之后的下一个状态,Stalled
开始时已经出队,他们太显著的差别(是否使用proxy/ssl
),他们之间没有and/or/parent/child
的关系,有建议将queueing/stalled
改名为postponed/awaiting socket
,具体可以看看chromium issue。
注意2:
另外,同源链接复用可能引发这样的问题,由于之前存在可用链接,此时浏览器希望重用之前的连接以节省资源,用之前的一个socket去发起连接,后收到服务器返回的链接已重置/不存在,再从原本可用链接中找可用链接,引发长时间等待,具体可以看看 chrome-stalled-problem-resolving-process
3、Proxy Negotiation
与代理服务器连接协商所用的时间。
主要是浏览器通过代理服务器去服务目标服务,如本地代理Fiddler
,一般无法优化。
4、DNS Lookup
DNS
查询所用的时间
-
可优化部分
- 不要有太多的新域名(可能递归查询绕地球一圈),参考
域名收敛
。 - 减少
DNS
解析路径(如果内部有很多DNS
服务器解析)。
- 不要有太多的新域名(可能递归查询绕地球一圈),参考
5、Initial Connection / Connecting
建立连接所用的时间,包括TCP 握手/重试
和协商 SSL
的时间。
6、SSL
完成SSL
握手所用的时间。
-
可优化部分
- 需要区分好什么资源需要
https
,什么需要http
。
- 需要区分好什么资源需要
7、Request Sent / Sending
发出网络请求所用的时间。通常不到一毫秒。
8、Waiting (TTFB)
等待初始响应所用的时间,也称为至第一字节的时间。
-
可优化部分
* 服务器响应速度 * 服务器网络带宽
9、Content Download / Downloading
接收响应数据所用的时间。
-
可优化部分
* 服务器网络带宽 * 单个文件大小
其他
大佬们总说要写文章,第一次写文章,就搬运了一下都感觉好难哦。
有不对的地方欢迎大佬们指出。
参考
Understanding Resource Timing
Chrome Cache Lock
Chromium Issues 476749
chrome-stalled-problem-resolving-process
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。