浏览器原理 20 # Chrome开发者工具：利用网络面板做性能分析

说明

浏览器工作原理与实践专栏学习笔记

DevTools

Chrome 开发者工具（简称 DevTools）是一组网页制作和调试的工具，内嵌于 Google Chrome 浏览器中。它提供了通过界面访问或者编辑 DOM 和 CSSOM 的能力，还提供了强大的调试功能和查看性能指标的能力。

Chrome 开发者工具最新版本

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 花费了大量时间，有可能是字节数太多的原因导致的。

解决：

减少文件大小，比如压缩、去掉源码中不必要的注释等方法。