说明
浏览器工作原理与实践专栏学习笔记
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 花费了大量时间，有可能是字节数太多的原因导致的。
解决：
减少文件大小，比如压缩、去掉源码中不必要的注释等方法。
