Network Resource Timing 我的请求慢在哪

最新推荐文章于 2024-08-17 18:52:33 发布

转载最新推荐文章于 2024-08-17 18:52:33 发布 · 574 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：https://segmentfault.com/a/1190000015133004

文章标签：

#网络 #运维

本文详细介绍了导致网页加载缓慢的九大因素，包括请求排队、代理协商、DNS查询等，并针对每一项提供了可行的优化建议。

前言

如果我们发现自己页面加载慢，通常会打开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