5 分钟撸一个前端性能监控工具

简单而言，有三点原因：

• 关注性能是工程师的本性 + 本分；
• 页面性能对用户体验而言十分关键。每次重构对页面性能的提升，仅靠工程师开发设备的测试数据是没有说服力的，需要有大量的真实数据用于验证；
• 资源挂了、加载出现异常，不能总靠用户投诉才后知后觉，需要主动报警。

一次性能重构，在千兆网速和万元设备的条件下，页面加载时间的提升可能只有 0.1%，但是这样的数（土）据（豪）不具备代表性。网络环境、硬件设备千差万别，对于中低端设备而言，性能提升的主观体验更为明显，对应的数据变化更具备代表性。

不少项目都会把资源上传到 CDN。而 CDN 部分节点出现问题的时候，一般不能精准的告知“某某，你的 xx 资源挂了”，因此需要我们主动监控。

根据谷歌数据显示，当页面加载超过 10s 时，用户会感到绝望，通常会离开当前页面，并且很可能不再回来。

用什么监控

关于前端性能指标，W3C 定义了强大的 Performance API，其中又包括了 High Resolution Time 、 Frame Timing 、 Navigation Timing 、 Performance Timeline 、Resource Timing 、 User Timing 等诸多具体标准。

本文主要涉及 Navigation Timing 以及 Resource Timing。截至到 2018 年中旬，各大主流浏览器均已完成了基础实现。

 

 

Performance API 功能众多，其中一项，就是将页面自身以及页面中各个资源的性能表现（时间细节）记录了下来。而我们要做的就是查询和使用。

读者可以直接在浏览器控制台中输入 performance ，查看相关 API。

接下来，我们将使用浏览器提供的 window.performance 对象（Performance API 的具体实现），来实现一个简易的前端性能监控工具。

5 分钟撸一个前端性能监控工具

第一行代码

将工具命名为 pMonitor，含义是 performance monitor。

const pMonitor = {}
复制代码

监控哪些指标

既然是“5 分钟实现一个 xxx”系列，那么就要有取舍。因此，本文只挑选了最为重要的两个指标进行监控：

• 页面加载时间
• 资源请求时间

看了看时间，已经过去了 4 分钟，小编表示情绪稳定，没有一丝波动。

 

 

页面加载

有关页面加载的性能指标，可以在 Navigation Timing 中找到。Navigation Timing 包括了从请求页面起，到页面完成加载为止，各个环节的时间明细。

可以通过以下方式获取 Navigation Timing 的具体内容：

const navTimes = performance.getEntriesByType('navigation')
复制代码

getEntriesByType 是我们获取性能数据的一种方式。performance 还提供了 getEntries 以及 getEntriesByName 等其他方式，由于“时间限制”，

返回结果是一个数组，其中的元素结构如下所示：

{
 "connectEnd": 64.15495765894057,
 "connectStart": 64.15495765894057,
 "domainLookupEnd": 64.15495765894057,
 "domainLookupStart": 64.15495765894057,
 "domComplete": 2002.5385066728431,
 "domContentLoadedEventEnd": 2001.7384263440083,
 "domContentLoadedEventStart": 2001.2386167400286,
 "domInteractive": 1988.638474368076,
 "domLoading": 271.75174283737226,