搞懂前台页面性能监控

为什么要监控页面性能？

一个页面性能差的话会大大影响客户体验。客户打开页面等待的太久，可能会直接关掉页面，甚至就不再使用了，这种情况在手机端更加显著，手机端客户对页面响应推迟容忍度很低。
尽管页面性能很重要，但是在实际使用中，页面性能差的情况并不少见。首先，在产品的迭代演进过程中，页面性能可能会被忽略，性能随着版本迭代而有所衰减；其次，性能优化是一项复杂而挑战的事情，需要明确的优化方向和具体的优化手段才能快速落地取效。
所以我们需要一个性能监控系统，持续监控和预警页面性能的状况，并且在发现瓶颈的时候指导优化工作。

了解Navigation Timing API的性能指标

为了帮助开发者更好地衡量和改进前台页面性能，W3C性能小组引入了 Navigation Timing API ，实现了自动、精准的页面性能打点；开发者可以通过 window.performance 属性获取。

下图是W3C第一版的 Navigation Timing 的解决模型。从当前浏览器窗口卸载旧页面开始，到新页面加载完成，整个过程一共被切分为 9 个小块：提醒卸载旧文档、重定向/卸载、应用缓存、DNS 解析、TCP 握手、HTTP 请求解决、HTTP 响应解决、DOM 解决、文档装载完成。每个小块的首尾、中间做事件分界，取 Unix 时间戳，两两事件之间计算时间差，从而获取中间过程的耗时（准确到毫秒级别）。

image.png

上图是 Level 1 的规范，2012 年底进入候选建议阶段，至今仍在日常使用中；但是在W3C的议程上，它已经功成身退，让位给了精度更高，功能更强大，层次更分明的 Level 2（解决模型如下图）。比方独立划分出来的 Resource Timing，使得我们可以获取具体资源的详细耗时信息

image.png

指标解读

image.png

采集页面性能的关键指标

image.png

确定统计起始点 （navigationStart vs fetchStart ）

页面性能统计的起始点时间，应该是客户输入网址回车后开始等待的时间。一个是通过navigationStart获取，相当于在URL输入栏回车或者者页面按F5刷新的时间点；另外一个是通过 fetchStart，相当于浏览器准备好使用 HTTP 请求获取文档的时间。
从开发者实际分析使用的场景，浏览器重定向、卸载页面的耗时对页面加载分析并无太大作用；通常建议使用 fetchStart 作为统计起始点。

首字节

主文档返回第一个字节的时间，是页面加载性能比较重要的指标。对客户来说一般无感知，对于开发者来说，则代表访问网络后台的整体响应耗时。

白屏时间

客户看到页面展现出现一个元素的时间。很多人认为白屏时间是页面返回的首字节时间，但这样其实并不准确，由于头部资源还没加载完毕，页面也是白屏。
相对来说具有「白屏时间」统计意义的指标，可以取 domLoading - fetchStart，此时页面开始解析DOM树，页面渲染的第一个元素也会很快出现。
从W3C Navigation Timing Level 2 的方案设计，可以直接采用 domInteractive - fetchStart ，此时页面资源加载完成，即将进入渲染环节。

首屏时间

首屏时间是指页面第一屏所有资源完整展现的时间。这是一个对客户来说非常直接的体验指标，但是对于前台却是一个非常难以统计衡量的指标。

具有肯定意义上的指标可以使用，domContentLoadedEventEnd - fetchStart，甚至使用loadEventStart - fetchStart，此时页面DOM树已经解析完成并且显示内容。

以下给出统计页面性能指标的方法。

let times = {};let t = window.performance.timing;// 优先使用 navigation v2  https://www.w3.org/TR/navigation-timing-2/if (typeof win.PerformanceNavigationTiming === 'function') {  try {    var nt2Timing = performance.getEntriesByType('navigation')[0]    if (nt2Timing) {      t = nt2Timing    }  } catch (err) {  }}//重定向时间times.redirectTime = t.redirectEnd - t.redirectStart;//dns查询耗时times.dnsTime = t.domainLookupEnd - t.domainLookupStart;//TTFB 读取页面第一个字节的时间times.ttfbTime = t.responseStart - t.navigationStart;//DNS 缓存时间times.appcacheTime = t.domainLookupStart - t.fetchStart;//卸载页面的时间times.unloadTime = t.unloadEventEnd - t.unloadEventStart;//tcp连接耗时times.tcpTime = t.connectEnd - t.connectStart;//request请求耗时times.reqTime = t.responseEnd - t.responseStart;//解析dom树耗时times.analysisTime = t.domComplete - t.domInteractive;//白屏时间 times.blankTime = (t.domInteractive || t.domLoading) - t.fetchStart;//domReadyTimetimes.domReadyTime = t.domContentLoadedEventEnd - t.fetchStart;

注意点

通过window.performance.timing所获的的页面渲染所相关的数据，在SPA应用中改变了url但不刷新页面的情况下是不会升级的。因而仅仅通过该api是无法取得每一个子路由所对应的页面渲染的时间。假如需要上报切换路由情况下每一个子页面重新render的时间，需要自己设置上报。

原文链接：10分钟彻底搞懂前台页面性能监控