简单而言,有三点原因:
- 关注性能是工程师的本性 + 本分;
- 页面性能对用户体验而言十分关键。每次重构对页面性能的提升,仅靠工程师开发设备的测试数据是没有说服力的,需要有大量的真实数据用于验证;
- 资源挂了、加载出现异常,不能总靠用户投诉才后知后觉,需要主动报警。
一次性能重构,在千兆网速和万元设备的条件下,页面加载时间的提升可能只有 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,