深入浅出 Performance 工具 & API

发表于 3年以前 | 总阅读数：350 次

概述

日常开发任务中，对于性能优化或多或少会接触到一些内容，可能也参照过雅虎 35 条军规[1]进行过相关的性能优化，但是具体的优化结果以及实际的页面速度如何，我们怎么去看呢？以及出现性能问题了，我们如何通过现有工具进行定位&解决？也就是今天我要给大家介绍的内容主题了「Performance」，主题偏向工具介绍，主要从下面 4 个方面介绍今天的内容。

Chrome Perormance 工具使用：介绍如何使用浏览器提供的工具定位
Performance Api 监测网页性能：介绍如何自己去做性能数据的提取
现存检测工具：三方性能检测工具介绍
Performance 工具小试：通过一个小例子运用 Performance

Chrome Performance 工具使用

Chrome 中 Performance 可以在上图中看到，主要分了几个板块

控制面板（Controls）

开启记录，停止记录，配置记录期间需要记录的内容。

操作主要分了 2 个区域，操作 1 区从左到右依次是 "Record/Stop"、"Reload"和"Clear"，

"Record/Stop"：一般用于录制页面交互过程的性能变化数据，选择任意想要测试的过程，点击"Record"，并在测量结束之后，点击"Stop"，之后 Chrome 就会自动解析这段时间内抓取的数据，并生成报告。
"Reload"：一般用于录制首屏加载的性能变化数据，它会自动刷新整个页面，并开始记录性能。
"Clear"：用于清除性能报告数据

操作 2 区可以选择报告展示内容，从左到右依次是 Screenshots、Memory、Web Vitals

Screenshots：打开后可以在概览区看到屏幕的截图
Memory：打开内存监控
WebVitals

概览面板（Overview）

主要是对页面表现行为的一个概述，区域由三个图形记录组成。

FPS（Frames Per Second）:绿色的柱越高， FPS 值也越高。FPS 图表上方的红色小块指明了长帧(long frame)，这些可能是卡顿。

CPU(CPU Resources):这个面积图(area chart)表明了哪种事件在消耗 CPU 资源。
NET:每种不同颜色的条代表一种资源。
条越长表明获取该资源所花的时间越长。
每个条中的浅色部分代表等待时间（资源请求被发送到收到第一个响应字节的时间），深色部分代表文件传输时间（从收到第一个字节到这个资源完全被下载好）
蓝色代表 HTML 文件，黄色代表 Script 文件，紫色代表 Stylesheets 文件，绿色代表 Media 文件，灰色代表其他资源。

火焰图（Flame Chart）

火焰图（Flame Chart）: 可视化 CPU 堆栈(stack)信息记录。
从不同的角度分析框选区域。例如：Network，Frames, Interactions, Main 等
在火焰图面板上你可能看到三根垂直的线，蓝线代表 DOMContentLoaded 事件，绿线代表渲染开始的时间( time to first paint)，红线代表 load 事件。

其实这里我们主要需要关注 Main，因为他是主线程的一个执行情况的监控。点开后，我们可以看当前线程里面一些任务的执行堆栈耗时，我们需要重点关注一些标红（也就是有较高耗时）的任务。

详细信息（Detail）

当有具体事件被选择时，该面板展示这个事件的更多详细信息。如果没有事件被选择，该面板展示当前所选时间段的一些信息。详细面板支持精确到毫秒级别的分析，详细面板主要分了

Summary 面板：从宏观层面概括了浏览器加载的总时间，主要记录了各个阶段的名称、占用时间、颜色信息。这里一般来说，需要着重关注的有两个：一是黄色的区域，代表脚本执行时间，另一个是紫色的渲染时间。
颜色：蓝色；英文：Loading；含义：加载
颜色：黄色；英文：Scripting；含义：脚本
颜色：紫色；英文：Rendering；含义：渲染
颜色：绿色；英文：Painting；含义：绘制
颜色：深灰；英文：Other；含义：其他
颜色：浅灰；英文：Idle；含义：空闲
Bottom-Up 面板：Bottom-Up 中一共三列数据
Self Time：代表任务自身执行所消耗的时间。
Total Time：代表此任务及其调用的附属子任务一共消耗的时间。
Activity：具体的活动，部分带有 Source Map 链接，可以直接定位到花费时间的具体源码，方便我们进行定位和优化。Activity 中也有标注各自的颜色，和 Summary 中颜色是对应的。可以根据颜色快速判断是脚本执行、加载、还是渲染过程。

Call-Tree 面板：Bottom-Up 类似事件冒泡，Call Tree 类似事件捕获。自上而下的 Call-Tree 更符合我们的人类正常思维，可以更直观地分析浏览器对页面的 build 精确到毫秒级的情况
Event-Log 面板：展示所有阶段包括 loading、javascripting、rendering、painting 中各事件的耗时情况，并提供了 filter 输入框和按钮供你快速过滤，常见的优化级别中一般用不到它。

Performance Api 监测网页性能

除了浏览器为我们提供的 Performance 性能检测调试工具外，W3C 也定义了一套 Performance 标准，各个浏览器厂商基于标准提供了监控网络性能的一系列基础 Api，这些 Api 可以提供检测白屏时间、首屏时间、用户可操作的时间节点，页面总下载的时间、DNS 查询的时间、TCP 链接的时间等。我们完全可以利用这个搭建一个简易的性能监控工具，当然监控系统包含了数据采集->数据存储->清洗->监控几个过程，不过目前我们这里简单运用一下 Performance Api 就只考虑采集阶段。

提供的能力

1 . 属性篇

performance 的所有 Api&property 挂载在 window 下面的 performance 属性中，可以看到目前提供的一系列属性，关于各个属性的介绍，参照网上对 aip 的解释，有大量资料可供查询。

如上图所展现，performance 包含三个对象，分别为memory、navigation、timing

memory：是和内存相关的，其提供对内存使用情况的描述，我们可以使用这个属性来订阅页面内存变化情况
jsHeapSizeLimit：堆内存大小的限制
totalJSHeapSize：总堆内存的大小
usedJSHeapSize：已经使用的堆内存大小
navigation：含义是页面的来源信息，表述页面怎么跳转过来的，该对象有 2 个属性值
redirectCount**：**记录重定向次数，如果有重定向的话，页面通过几次重定向跳转而来，默认为 0
type**：**页面打开的方式，默认为 0，可取值为「0：表示正常进入该页面(非刷新、非重定向)」、「1：表示通过 window.location.reload 刷新的页面」、「2：表示通过浏览器的前进、后退按钮进入的页面」、「255：表示非以上的方式进入页面的」
timing：提供页面加载过程中一系列关键时间点的高精度测量，它包含了网络、解析、加载等一系列的时间数据，我们监控网页性能也是基于此提供的属性。为了方便理解，从网上找了一张图片来解释关键节点的含义。

navigationStart**：**一个页面卸载结束时的时间戳。如果没有上一个页面的话，那么该值会和 fetchStart 的值相同
redirectStart**:**第一个 http 重定向开始的时间戳，如果没有重定向，或者重定向到一个不同源的话，那么该值返回为 0
redirectEnd**:**最后一个 HTTP 重定向完成时的时间戳。如果没有重定向，或者重定向到一个不同的源，该值也返回为 0
fetchStart**:**浏览器准备好使用 http 请求抓取文档的时间(发生在检查本地缓存之前)。
domainLookupStart**:**DNS 域名查询开始的时间，如果使用了本地缓存话，或持久链接，该值则与 fetchStart 值相同
domainLookupEnd**:**DNS 域名查询完成的时间，如果使用了本地缓存话，或持久链接，该值则与 fetchStart 值相同
connectStart**:**HTTP 开始建立连接的时间，如果是持久链接的话，该值则和 fetchStart 值相同，如果在传输层发生了错误且需要重新建立连接的话，那么在这里显示的是新建立的链接开始时间
secureConnectionStart**:**HTTPS 连接开始的时间，如果不是安全连接，则值为 0
connectEnd：HTTP 完成建立连接的时间(完成握手)。如果是持久链接的话，该值则和 fetchStart 值相同，如果在传输层发生了错误且需要重新建立连接的话，那么在这里显示的是新建立的链接完成时间
requestStart**:**http 请求读取真实文档开始的时间，包括从本地读取缓存，链接错误重连时
responseStart**:**开始接收到响应的时间(获取到第一个字节的那个时候)。包括从本地读取缓存
responseEnd**：**HTTP 响应全部接收完成时的时间(获取到最后一个字节)。包括从本地读取缓存
unloadEventStart**:**前一个网页（和当前页面同域）unload 的时间戳，如果没有前一个网页或前一个网页是不同的域的话，那么该值为 0
unloadEventEnd**:**和 unloadEventStart 相对应，返回是前一个网页 unload 事件绑定的回调函数执行完毕的时间戳。
domLoading**:**开始解析渲染 DOM 树的时间
domInteractive**:**完成解析 DOM 树的时间（只是 DOM 树解析完成，但是并没有开始加载网页的资源）
domContentLoadedEventStart**：**DOM 解析完成后，网页内资源加载开始的时间
domContentLoadedEventEnd**:**DOM 解析完成后，网页内资源加载完成的时间
domComplete**:**DOM 树解析完成，且资源也准备就绪的时间。Document.readyState 变为 complete，并将抛出 readystatechange 相关事件
loadEventStart**:**load 事件发送给文档。也即 load 回调函数开始执行的时间，如果没有绑定 load 事件，则该值为 0
loadEventEnd**:**load 事件的回调函数执行完毕的时间，如果没有绑定 load 事件，该值为 0

2 . 方法篇

如上图，截取的图片，Performance 提供了一些，这里我主要介绍一下 now()方法和 getEntries()方法。其他的网上资料也比较多和全，可以查阅 https://juejin.cn/post/6844903801518981133#heading-54

now 方法：提供精度相对较高的时间计算主要有下面两个特点
和 JavaScript 中其他可用的时间类函数（比如Date.now）不同的是，window.performance.now()返回的时间戳没有被限制在一毫秒的精确度内，相反，它们以浮点数的形式表示时间，精度最高可达微秒级。
另外一个不同点是，window.performance.now()是以一个恒定的速率慢慢增加的，它不会受到系统时间的影响（系统时钟可能会被手动调整或被 NTP 等软件篡改）。

我们可以用这个方法来衡量函数执行的时间，达到监控函数执行效率的效果

`const fun = () => {

// do something

}

const startExcuteTime = window.performance.now();

fun();

const endExcuteTime = window.performance.now();

console.log("fun 函数执行了" + (endExcuteTime - startExcuteTime) + "毫秒.")  
`

getEntries 方法：通过该方法，我们能够拿到页面所有资源请求的详细情况，这个方法返回值根据传入的参数不同会有不同。但返回值的结构都是一样的，都是一个对象数组，每个对象是对资源的请求过程的描述，在 console 调用 performance.getEntries()，可以直接看到当前页面所有资源的加载过程。

点开数组中的元素，每个元素详细记录了资源请求关键节点的时间，所以我们完全可以利用这个来实现对资源的请求监控。

更多 Api 细节，可以参考司内文章再看一次 Performance 接口[2]

简单实现指标计算

一个监控系统大致可以分为这个下面阶段，我们这里就先关注一下数据的采集阶段。数据采集阶段设计到两点，一个是数据的搜集，一个是数据的上报。

数据的搜集：数据搜集依赖于 Performance Api 拿到性能数据，我们参照一定的计算指标，得到计算值的集合。
数据的上报：将搜集到的数据上报到服务器，上报使用的方式也就是发送一个 http 请求，不过目前因为监控数据采用 XHR 的请求上报，受到条件限制比较多，数据容易丢失，容易漏报，且对页面性能有一定的影响。而 sendBecan 是浏览器为了解决这些问题，它会使用户代理在有机会时异步地向服务器发送数据，同时不会延迟页面的卸载或影响下一导航的载入性能。这就解决了提交分析数据时的所有的问题：数据可靠，传输异步并且不会影响下一页面的加载。具体可以参考：https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/sendBeacon

下面是 Slardar 源码截图，可以看到他们上报监控数据优先采用的 sendBecan，降级策略为 XHR 请求。

可以通过 performance api 来实现我们经常关注的一些指标的计算和上报

`重定向耗时 = redirectEnd - redirectStart;

DNS 查询耗时 = domainLookupEnd - domainLookupStart;

TCP 链接耗时 = connectEnd - connectStart;

HTTP 请求耗时 = responseEnd - responseStart;

解析 dom 树耗时 = domComplete - domInteractive;

白屏时间 = responseStart - navigationStart;

DOMready 时间 = domContentLoadedEventEnd - navigationStart;

onload 时间 = loadEventEnd - navigationStart; `

现存的一些网页性能检测工具

除了前面两种方式能够检测页面性能外，还有一些三方的工具 or 平台为我们提供了检测能力。

LightHouse
PageSpeed
YSlow

下面是使用 LightHouse 的截图，Lighthouse 生成的不仅仅是一些性能相关的数据，他除了能给我们提供页面性能检测外，还为我们列出了一系列的优化建议，我们对网站或者页面的优化，可以参照建议一步步进行优化。

React 中性能定位工具

提供组件级别的渲染分析React 性能测量和分析[3]React Profiler 介绍 – React Blog[4]

Performance 工具小试

学浪老师端项目代码目前跑在两个大的宿主环境中「CEF 套壳」「浏览器」，项目一期的时候，整体项目是采用的单入口多路有方式，并且来说项目的打包也没有优化，整体上呈现出

访问混乱（浏览器能访问 CEF 壳子内的一系列路由）
打包混乱（出现多种重复打包，导致编译慢）
引用混乱（因为是是一套入口，很多只是在 CEF 内引用的文件，在单入口文件中引用了，导致浏览器加载了一系列不必要的静态资源）

上面的一系列问题，导致学浪整体页面加载速度非常的慢，后续学浪侧专门组织了一次大的重构优化，进行了项目入口的拆分&打包过程的的拆分，整体上现的学浪项目结构是多入口多路由，且区分宿主环境的。从目前的表现来看，页面的加载速度相对于以前提升了非常多。目前的加载时长度在我当前网络情况下 DomContentLoad 大概在 2S 左右

是否还有优化空间，将页面加载时间降得更低？我们可以通过 Performance 的 NetWork 火焰图看看到底是哪些文件的加载耗时长，延长了 DomContentLoad 触发时机。首先 DomContentLoad 事件触发影响因素有 html 下载、dom 解析、js 脚本下载&执行，都会影响 DomContentLoad 触发。

通过观察 NetWork 的情况，很明显看到 DCL 的时机，在一个 encoding.js 文件加载完成后，再触发的，而这个文件的加载时间长达 2.13s，可谓是占据了首页加载的 80%左右的时间，那么就想如何优化这个脚本的加载时长？有几种思路

压缩 encoding.js 使得体积减小（前提是没有压缩的情况下）
看是否是首页强依赖文件（如果是后续依赖，可以采用异步脚本 defer or async 来解决下载阻塞了 DomContentLoad 问题）
看是否真正有使用（最好的办法就是不用，这样就完全省去了时间）
当然还有其他一系列客户端缓存、cdn 加速等一系列策略

找到了原因和思路，于是开始先对文件背景溯源，发现由于这个文件是为了处理一些教室内 sdk 在不同浏览器內的 pollfiy，但是目前因为通过阶段一的大包&入口的拆分，教室内 sdk 的相关资源不会出现在浏览器环境加载了，因此在浏览器环境内实际不再使用，godless 我们可以直接删除，看下效果。（实际看 encoding.js 文件也是没有压缩过的，如果实际文件有在用，我们可以采取使用压缩文件）

整体上 DCL 的触发时间由 2.13s 降低为 972ms，效果还是比较明显的。通过一个很小的分析案例+很小的优化说明下 Performance 面板中相关模块的使用。