说明
浏览器工作原理与实践专栏学习笔记
DevTools
Chrome 开发者工具(简称 DevTools)是一组网页制作和调试的工具,内嵌于 Google Chrome 浏览器中。它提供了通过界面访问或者编辑 DOM 和 CSSOM 的能力,还提供了强大的调试功能和查看性能指标的能力。
10 个功能面板
打开 Chrome 开发者工具(f12,或者更多工具–> 开发者工具,ctrl+shift+i
)
Elements、Console、Sources、NetWork、Performance、Memory、Application、Security、Audits 和 Layers。
接下来重点讲一讲 Network 面板,即网络面板。
Network 面板
从上面我们知道:
看一下网络面板概要图:
从图中可以看出:网络面板由控制器、过滤器、抓图信息、时间线、详细列表和下载信息概要这 6 个区域构成。
1. 控制器
4 个比较重要的功能需要知道
- 红色圆点的按钮:开始 / 暂停抓包
- 全局搜索按钮:在所有下载资源中搜索相关内容
- Disable cache:禁止从 Cache 中加载资源
- Online 按钮:可以限制带宽,用来模拟 2G/3G 功能,
控制器概要图:
2. 过滤器
可以通过过滤器模块来筛选想要的文件类型。便于我们查看。
3. 抓图信息
可以用来分析用户等待页面加载时间内所看到的内容,分析用户实际的体验情况。
比如,如果页面加载 1 秒多之后屏幕截图还是白屏状态,这时候就需要分析是网络还是代码的问题了。(勾选面板上的“Capture screenshots”即可启用屏幕截图。)
chrome开发者工具:Network面板篇的capture screenshots
4. 时间线
用来展示 HTTP、HTTPS、WebSocket 加载的状态和时间的一个关系,用于直观感受页面的加载过程。如果是多条竖线堆叠在一起,那说明这些资源被同时被加载。
5. 详细列表
记录了每个资源从发起请求到完成请求这中间所有过程的状态,以及最终请求完成的数据信息。
6. 下载信息概要
重点关注下 DOMContentLoaded
和 Load
两个事件,以及这两个事件的完成时间。
DOMContentLoaded
:页面已经构建好 DOM。(DOM 需要的 HTML 文件、JavaScript 文件、CSS 文件都已经下载完成)Load
:浏览器已经加载了所有的资源(图像、样式表等)
网络面板中的详细列表
1. 列表的属性
默认情况下,列表是按请求发起的时间来排序的,最早发起请求的资源在顶部。
可以通过点击右键的下拉菜单来添加其他属性:
2. 详细信息
选中详细列表中的一项,右边就会出现该项的详细信息:
3. 单个资源的时间线
浏览器中 HTTP 请求流程:
详细列表中是如何表示出这个流程的呢?
单个文件的时间线:
3.1 Queuing:排队:当浏览器发起一个请求的时候,不能被立即执行,而是需要排队等待。
导致该请求不能被立即执行的原因:
- 首先,页面中的资源是有优先级的
- 比如 CSS、HTML、JavaScript 等都是页面中的核心文件,所以优先级最高;而图片、视频、音频这类资源就不是核心资源,优先级就比较低。通常当后者遇到前者时,就需要“让路”,进入待排队状态。
- 其次,浏览器会为每个域名最多维护 6 个 TCP 连接,如果发起一个 HTTP 请求时,这 6 个 TCP 连接都处于忙碌状态,那么这个请求就会处于排队状态。
- 最后,网络进程在为数据分配磁盘空间时,新的 HTTP 请求也需要短暂地等待磁盘分配结束
3.2 Stalled:停滞:等待排队完成之后,就要进入发起连接的状态了。不过在发起连接之前,还有一些原因可能导致连接过程被推迟
chrome 的 timeline 中 stalled 问题解析
根据这一篇文章的描述:stalled 阶段时 TCP 连接的检测过程,如果检测成功就会继续使用该 TCP 连接发送数据,如果检测失败就会重新建立 TCP 连接。所以出现 stalled 阶段过长,往往是丢包所致,这也意味着网络或服务端有问题。
注意:如果你使用了代理服务器,还会增加一个 Proxy Negotiation 阶段,也就是代理协商阶段,它表示代理服务器连接协商所用的时间,不过在上图中没有体现出来,因为这里我们没有使用代理服务器。
3.3 Initial connection/SSL 阶段:服务器建立连接的阶段,包括了建立 TCP 连接所花费的时间;如果使用了 HTTPS 协议,那么还需要一个额外的 SSL 握手时间,这个过程主要是用来协商一些加密信息的。
3.4 Request sent 阶段:和服务器建立好连接之后,网络进程会准备请求数据,并将其发送给网络
通常这个阶段非常快,只需要把浏览器缓冲区的数据发送出去就结束了,并不需要判断服务器是否接收到了,所以这个时间通常不到 1 毫秒。
3.5 Waiting (TTFB):第一字节时间:等待接收服务器第一个字节的数据。
TTFB 是反映服务端响应速度的重要指标,对服务器来说,TTFB 时间越短,就说明服务器响应越快。
3.6 Content Download 阶段:从第一字节时间到接收到全部响应数据所用的时间
优化时间线上耗时项
1. 排队(Queuing)时间过久
排队时间过久,大概率是由浏览器为每个域名最多维护 6 个连接导致的。
怎么怎么处理?
1.1 利用域名分片技术:
让 1 个站点下面的资源放在多个域名下面,比如放到 3 个域名下面,这样就可以同时支持 18 个连接了,这种方案称为域名分片技术。
1.2 让站点升级到 HTTP2
HTTP2 已经没有每个域名最多维护 6 个 TCP 连接的限制了。
2. 第一字节时间(TTFB)时间过久
原因有如下:
- 服务器生成页面数据的时间过久
- 网络的原因
- 发送请求头时带上了多余的用户信息
与之对应的解决方案:
- 通过增加各种缓存的技术
- 使用 CDN 来缓存一些静态文件
- 发送请求时尽可能地减少一些不必要的 Cookie 数据信息
3. Content Download 时间过久
原因:
如果单个请求的 Content Download 花费了大量时间,有可能是字节数太多的原因导致的。
解决:
减少文件大小,比如压缩、去掉源码中不必要的注释等方法。