共计 3418 个字符，预计需要花费 9 分钟才能阅读完成。
网络 Network
瀑布流
随着网页的加载，每个 HTTP 请求都会是瀑布流中的一条。第一条都是文件 document 的加载，当文件被解析，随后通常是 CSS 文件的加载。和写在 HTML 文件中的标签中的顺序是一样的。但浏览器会做一些优化，比如会降低图片的优先度，提升 CSS 文件的优先度等。
在瀑布流下方的表格中，我们可以看到请求的 Name，Status，Type 等信息。Initiator 列的意思是，什么文件需求加载了这一行的文件。按住 Shift 点击表格的一行，调用该行文件的相应文件会变绿 (who called it?)，该行文件调用的相应行会变红 (who does it called?)。
瀑布流颜色
- 白色 队列中。不常见。HTTP1 中，浏览器一次性只能进行 6 个 TCP 连接，比如我们有 7 个 CSS 文件，那么其中的一个就会在队列中。
- 灰色 一个请求能发送前的各种停滞反应时间。
- 浅灰色 在 Proxy 代理服务器消耗的时间
- 深绿色 DNS 查找的时间
- 橙色 建立连接时间。包括 TCP 握手时间和建立 SSL 连接时间。
- 棕色 SSL 连接时间
- 绿色 等待回复的时间。也就是等待获得第一个字节的时间。如果绿色很长说明应用服务器很慢。
- 蓝色 下载回复内容的时间。和文件大小有关系。
快照
如果我们点击 Capture Screenshot 按钮，重新加载页面，就可以看到网页的每次 repaint，也就是网页是如何加载的。
使用这个功能，我们可以知道在慢速网络下，网页是如何呈现出来的。
过滤信息
Network 面板中，我们可以点击文件类型来查看特定类型的文件。左侧有个输入框也可以输入特定条件。比如 larger-than:200px，就可以观察大于 200px 的图片请求。
Disable Cache，Offline，Preserve Log 三个按钮的功能是显而易见的。
性能 Performance
开发者性能 VS 用户端性能测试
开发者性能测试是在开发环境中做性能测试，但是用户端是在真实用户使用的情况下记录测试数据。以前是这么做的：
const start = new Date().getTime();
const end = new Date().getTime();
const time = end - start;
这样我们就可以记录下用户作出一个操作的时间，然后将数据 post 回来。
后来有了 Performance API:
performance.mark('start')
performance.mark('end);
performance.measure('Our Measurement,'start','end');
performance.getEntriesByType('measure')图片性能
一般图片过大的解决方法：
- resize 图片
- 删除图片的 meta data
- 在服务器端使用 gzip，brotli, zopfli 等工具。
还有一个 HTML API 要知道，srcset
可以在不同窗口大小的时候加载指定的图片。
<img srcset="small.jpg 300w,
medium.jpg 800w,
large.jpg 1200w">但是为了浏览器兼容性，我们总是应该给默认的 src attribute 留一个 URL。
页面卡顿 Page Jank
为什么看起来卡
现代大多数屏幕刷新率都是 60 帧每秒。1 秒 /60 = 16.66 毫秒。所以我们的一个画面更新的处理时间如果超过了 16 毫秒，就感觉卡。
编译时间慢
有一种卡的原因是因为，解析 Javascript 的时间过长。V8 引擎渲染页面的时候，需要编译 Javascript，生成 AST(Abstract Syntax Tree)。当客户端的处理性能很差的时候，就要等很久。
布局抖动
还有一种卡的原因是因为，Layout thrashing，反复布局，又称布局抖动。
//Read
const h1 = element.clientHeight;
//Write
element1.style.height = (h1 * 2) + 'px';
//Read
const h2 = element2.clientHeight;
//Write
element2.sytle.height = (h2 * 2) + 'px';当我们反复进行这种 DOM 读写操作的时候，就会造成布局抖动。
requestAnimationFrame
如果我们可以将读和写完全分开，一次性操作所有读，一次性操作所有写，就不会有这种情况，但是这是不现实的。这就是使用 window.requestAnimationFrame() 的原因。
简单说 requestAnimationFrame 将读写操作和屏幕刷新率匹配起来，当浏览器准备好更新下一帧时，做想做的操作，减少性能浪费，避免跳帧。关于这个话题有很多写 Event Loop 的文章里也有写，这里不多写。
观察页面重绘情况
在开发者工具中，我们在更多工具中可以找到 Rendering 的选项。
打开这个选项，页面每次 repaint 的地方都会变成绿色，帮助开发者观察是否一些没必要重绘的地方在不停的被重绘，浪费性能。
录制操作和分析
我们点击录制按钮，在页面上做一些操作，比如 Scroll。Performance 面板中就会有一些数据。
最下方有一个饼状图是一个概括总结。
展开 Main 行，X 轴代表处理时间，Y 轴是 Call Stack。Y 轴高没关系，只是函数之间不断的调用，但是如果有色块很宽的话就说明处理时间很长。
我们可以使用 WASD 来操作。按 W Zoom In 可以看到具体信息。
找到一个很宽的色块，看之前是哪个色块调用了这个色块，然后我们就可以在下方 Summary 面板中找到具体文件名，点击去 Sources 面板看代码。
内存 Memory
JS 中的内存泄漏
当一些内存没有按开发者的意愿被释放的时候，就出现了内存泄漏。
常见的内存泄漏情况
- 意外添加的全局变量
function foo() {bar = "Hi"}当 foo 被调用的时候，因为 bar 没有变量声明关键词 const，var，let。JS 就会一直向上找这个变量到全局作用域，然后会为你创建一个全局变量 bar。当这个函数结束的时候，你以为这个 bar 会被回收，但其实它一直留在全局。设想如果这个 bar 不是“Hi”而是一个拥有很多元素的 array，它留在了全局作用域，这并不是我们想要的情况。
- 没有取消的计时器
顾名思义，计时器没有被取消或移除。
- 多余的 DOM 元素变量
const button = document.getElementById('button);
document.body.removeChild(document.getElementById('button)
);
}这里我们在 DOM 中移除了这个 button，但是之前指向这个元素的 reference 还在，就是变量 button。所以这个 reference 就留在了内存中。
发现内存泄漏
打开 Chrome 的任务管理器，确保 Javascript Memory 列有显示。我们可以看到每个标签页的内存使用情况。如果有一个标签页的内存使用不稳定，一直在上升，说明出现了内存泄漏。
在 Performance 面板记录下的数据中，如果我们打勾 Memory 选项，我们就可以看到 Memory 行。如果线图不停的上升，就说明出现了内存泄漏。
定位内存泄漏
在开发者工具的 Memory 面板中，我们可以选择 Heap Snapshot，记录一个当前页面具体内存使用情况的快照。注意 Shallow Size 列和 Retained Size 列。
Shallow Size 是对象自身占用内存的大小，而 Retained Size 是指我们移除 Object 后能获得多少空间，也就是将对象本身和连同的相关对象一起删除后释放的内存大小。比如一个变量指向一个很大的 Object，这个变量本身是个 reference 很小（Shallow Size 很小），但是移除这个变量以后，我们就可以获得很大的空间（Retained Size 很大 )。
我们可以根据 Shallow Size 给 Heap Snapshot 排序，找到占用内存最多的对象，如果不确认是否是内存泄漏，可以再记录一个 Heap Snapshot 做对比。如果该对象的 Shallow Size 增长了，说明确实出现了内存泄漏。我们可以根据工具给的提示信息，找到开发代码片段做修改。
评估 Audit
现在的 Audit 面板整合了谷歌的 Lighthouse 服务。网上还有一些其他不错的第三方服务如 webpagetest，sonarwhal。
官方文档
Chrome Developer Tool
