超全对照！前端监控的性能指标与数据采集

Posted 2021-06-18 QcloudCommunity

导语 | 前端监控可以让你更了解自己的网站，更早地发现和解决存在的问题，再通过优化来提升网站的性能和体验。那么，如何衡量一个网站的好坏？有什么指标？性能数据如何采集？本文围绕这些问题和你一起探讨。

一、为什么要做前端性能监控

可能你也有过这样的经历：

有用户反馈你的网站很慢，然后你立马紧张地在浏览器上打开用户反馈的网站。经过检查，可能你的网站一切正常，也可能你的网站真的很慢，甚至打不开了。

有一天老板问你：“咱们的网站性能体验怎么样？”你该如何回答？“挺好的，很快，这个月没有发生过故障....”老板再问：“怎么个好法？” “很快打开”“有多快？” “没统计过....” 然后就没有然后了.....

如果我们有前端监控，就有能力：

• 第一时间发现问题

  也许在用户反馈这个问题之前，该问题已经存在多日了，只是一直用户没有反馈。如果有性能方面的监控，可以第一时间去发现问题，及时解决，把影响面、影响时长降到最低。

• 全面掌握数据，驱动优化性能，提高系统稳定性

  通过监控采集到页面性能、用户使用方面的数据，可以系统、全面地掌握系统运行情况。

• 提升用户体验

  加快内容显示速度，缩短交互延时。

二、前端性能监控分类

性能监控，可分为两类：合成监控和真实用户监控。

1. 合成监控

模拟一个用户使用场景，提交需要进行分析的页面，再通过一系列的打点、分析去完成一些指标项的数据收集，最后呈现分析报告。例如Google的 Lighthouse，目前最新版的google chrome自带的页面性能分析工具。

调出开发工具（win: F12, mac: fn+f12)

Lighthouse主要三个指标：性能、可交互性、最佳实践。

在性能方面，具体的指标有：

• First Contentful Paint 首次内容渲染；

• Time to Interactive 可交互时间；

• Speed Index 速度指数；

• Total Blocking Time 总的阻塞时间;

• Largest Contentful Paint 最大内容渲染；

• Cumulative Layout Shift 累积布局偏移；

每一项指标还会给出具体的优化建议，例如性能方面的优化建议：

Lighthouse 系统架构图：

2. 真实用户监控

真实用户监控, 记录的是真实的用户当时访问页面时的真实的数据，在访问结果时把采集到的数据上报到服务器，再经过数据清洗、加工等工作后，在监控平台上呈现监控数据。

3. 合成监控和真实用户监控的区别

合成监控的优缺点：

优点	缺点
使用简单，现有工具	模拟用户场景，无法全部还原真实场景
采集数据丰富，如硬件指标、瀑布图	单次运行，数据不够稳定
不影响真实用户访问性能	数据量少，无法覆盖所有场景

真实用户监控的优缺点：

优点	缺点
采集用户真实使用数据	无法采集到硬件相关信息
样本量大，可以全覆盖，减少统计误差	因需要上报，无法采集完整的资源加载瀑布图
性能数据与其它数据关联产生更大的价值	无法可视化展示页面加载过程

区别：

对比项	合成监控	真实用户监控
实现难度&成本	较低	较高
采集数据丰富度	丰富	基础
采集样本量	小	大
适用场景	自有业务，用户量小，定性分析	中台产品，用户量大，定量分析

因为真实用户监控也是在运行时执行，所以这种真实用户监控比较难采集到一些硬件相关的指标，也很难去采集这个页面执行的幻灯片（即逐帧截图）。当然技术上可以用JS把当前页面保存成一个Canvas，做一些逐帧对比，甚至把这些数据回传回去。但是在实践过程中，我们肯定不会这样做，因为这对用户的流量是极大的浪费。介绍完这两种监控方案我们来看它们的对比。

本文要讲的是真实用户监控。

三、前端性能如何衡量

1. Google Web Vitals

评估一个网站的用户体验涉及到多个指标，有些还与网站的内容有关，但还是有一些共性的指标的，而Core Web Vitals体现了最关键的几项指标。此类核心用户体验需求包括页面内容的加载体验、交互性和视觉稳定性，这些方面共同组成 2020 Core Web Vitals 的基础。

• LCP：Largest Contentful Paint，显示最大内容元素所需时间 (衡量网站初次载入速度)；

• FID：First Input Delay 首次输入延迟时间 (衡量网站互动顺畅程度)；

• CLS：Cumulative Layout Shift 累计布局位移 (衡量网页元件视觉稳定性)；

除了以上三个主要衡量指标，还有FCP和TTFB：

• FCP: First Contentful Paint 首次内容绘制，标记浏览器渲染来自 DOM 第一位内容的时间点；

• TTFB: Time To First Byte 读取页面第一个字节的时间；

虽然LCP最大内容绘制是最重要的负载指标，但其也高度依赖于首次内容绘制 (FCP) 和首字节响应时间 (TTFB)，这些指标对监控和改进均具有非常重要的意义。

2. API耗时

很多时候页面上的数据是通过异步请求后台API后再进行渲染得到的，API耗时直接影响了LCP数据和用户体验。

• LCP 最大内容渲染

LCP以用户为中心，来衡量页面加载“完成”所用的时间，当页面中最大一块内容被渲染出来时，被认为是页面加载“完成”了。以前，用load\\DOMContentLoaded件反应页面加载速度，后来使用了更精准的FCP（首次内容渲染），但是从用户角度出发，只有主要的内容显示出来了才算是加载完成。

其最大指的是实际Element长宽大小，Margin / Padding / Border等CSS大小效果不计入。包含的种类为<img>,url,<video>及包含文字节点的Block或Inline Element，未来可能会再加入<svg>。因为网页上的Element可能持续加载，最大的Element也可能持续改变 (如文字载入完，然后载入图片) ，所以当每一个当下最大的Element载完，浏览器会发出一个PerformanceEntry Metric，直到使用者可以进行Keydown / Scrolling / Tapping等操作，Browser才会停止发送Entry，故只要抓到最后一次Entry，即能判断LCP的持续时间。

如下图所示，绿色区域是LCP不断改变的侦测对象，也能看到FCP与LCP的判断差异。

• FID 衡量网站互动顺畅程度

如何衡量网站操作的顺畅程度，Google采用FID指标，其定义为在TTI的时间内第一个互动事件的开始时间与浏览器回应事件的时间差，其互动事件为单次事件如Clicks / Taps / Key Presses等，其他连续性事件Scrolling / Zooming则不计，如下图所示：

为什么要取在TTI发生的第一次的操作事件，Google给的理由有以下三点：

1）使用者的第一次互动体验印象相当重要

2）当今网页最大的互动性问题通常发生在一开始载入时，页面载入完后的第二次操作事件延迟，有其他专门的改善解决建议。

3）但是FID的计算有其明显的问题，如当使用者在Main Thread闲置时操作，那FID可能就短，若不操作则FID则无法计算。这对开发者来说，很难去衡量网站的FID符合良好的标准，所以Google给的建议是透过降低TBT的时间来降低FID的值，当TBT越短，其FID就越好。

• CLS 衡量网页元件视觉稳定性

你可能有过这样的经历， 当你准备点某一个按钮或内容是，它突然移动了，然后你点了另外一个按钮。

例如下图，当你准备点击“确认提交”按钮时，按钮上方加载了一个提示框，导致下面的按钮被往下移动，在你原来要点击的位置的元素由原来的“确认提交”按钮，变成了“放弃申请”按钮。在你点击时，变成了放弃该订单，前面的工作白白被浪费了，这是大家都不愿意看到的，体验非常不好，令人抓狂。

导致这种预料之外的的内容布局移动，可能是因为资源的异步加载、JS对dom元素的动态操作、未知尺寸图片加载等等。对用户来说，这是一种糟糕的用户体验。CLS就是用来衡量此类的体能指标。

什么是一个好的CLS分数？75%以上的用户小于0.1。

• 布局偏移的具体内容

布局偏移是由Layout Instability API定义的。这个API会在任意时间上报layout-shift的条目，当一个可见元素在两帧之间，改变了它的起始位置（默认的writing mode下指的是top和left属性）。这些元素被当成不稳定元素。

需要注意的是，布局偏移只发生在已经存在的元素改变起始位置的时候。如果一个新的元素被添加到dom上，或者已存在的元素改变它的尺寸，除非改变了其他元素的起始位置，否则都不算布局偏移。

其 CLS 代表的是每个元素非预期位移的累积，而每个位移的算法如下: 元素位移分数 (Layout Shift Score) = 影响范围 (Impact Fraction) * 移动距离 (Distance Fraction)。

上图中，元素在一帧中占了屏幕的一半。下一帧，元素下移了25%的视图高度。红色虚线框起来的部分就是不稳定元素在两帧的占的视图总和（75%），所以影响分数是0.75。

上图，不稳定元素在纵向移动了25%，所以距离分数是0.25。

所以布局偏移分数是：

CLS: 0.75 * 0.25 = 0.1875

• API 指标关注哪些数据？

除了从请求到返回的耗时外，还有请求列队时间、请求发起时间。

如果一个API从发起请求到数据返回很快，但是由于需要列队等待或是依赖其它数据都原因而被推迟发起请求，从用户角色看，这也是一个很慢的接口。所以作为开发者还需要关注API请求是否能够尽快地被发起。

四、前端性能数据采集

通过上面的内容，我们了解了网站性能监控的一些指标，接下来看看这些指标数据是如何获取的。

1. web-vitals库

对于LCP、FID、CLS数据，可以直接安装web-vitals库：

????（https://github.com/GoogleChrome/web-vitals）

如何安装：

npm install web-vitals

使用方法：

import {getLCP,getFID,getCLS} from'web-vitals';
getCLS(console.log);
getFID(console.log);
getLCP(console.log);

打开页面，在浏览器控制台上就可以看到类似的数据：

 

实际使用时把console.log替换成你要处理的方法即可。当然，还可以使用getFCP、getTTFB方法来获取相应的数据。

2. performance API

为了帮助开发者更好地衡量和改进前端页面性能，W3C性能小组引入了Navigation Timing API，实现了自动、精准的页面性能打点。performance能提供哪些时间节点？在浏览器控制台中执行window.performance.timing；可以得到类似如下输出：

这些属性和值代表什么呢？之此之前，我们先来看下这张图：

上图是实时监控性能模型，可以看到我们的页面加载被定义成了很多个阶段。可以大致分为5个阶段：

1）开始计时

2）重定向

3）网络连接

4）数据交互

5）页面渲染

各属性对应的意义如下：

属性	说明
navigationStart	同一个浏览器上下文的上一个文档卸载结束时的时间戳，如果没有上一个文档，这个值会和fetchStart相同。
unloadEventStart	unload事件抛出时的时间戳,如果没有上一个文档，这个值会是0。
unloadEventEnd	unload事件处理完成的时间戳,如果没有上一个文档，这个值会是0。
redirectStart	第一个HTTP重定向开始时的时间戳，没有重定向或者重定向中的不同源，这个值会是0。
redirectEnd	最后一个HTTP重定向开始时的时间戳，没有重定向或者重定向中的不同源，这个值会是0。
fetchStart	浏览器准备好使用HTTP请求来获取文档的时间戳。发送在检查缓存之前。
domainLookupStart	域名查询开始的时间戳，如果使用了持续连接或者缓存，则与fetchStart一致。
domainLookupEnd	域名查询结束的时间戳，如果使用了持续连接或者缓存，则与fetchStart一致。
connectStart	HTTP请求开始向服务器发送时的时间戳，如果使用了持续连接，则与fetchStart一致。
connectEnd	浏览器与服务器之间连接建立（所有握手和认证过程全部结束）的时间戳，如果使用了持续连接，则与fetchStart一致。
secureConnectionStart	浏览器与服务器开始安全链接握手时的时间戳，如果当前网页不需要安全连接，这个值会是0。‍
requestStart	浏览器向服务器发出HTTP请求的时间戳。
responseStart	浏览器从服务器收到（或从本地缓存读取）第一个字节时的时间戳。
responseEnd	浏览器从服务器收到（或从本地缓存读取）最后一个字节时（如果在此之前HTTP连接已经关闭，则返回关闭时）的时间戳。
domLoading	当前网页DOM结构开始解析时的时间戳。
domInteractive	当前网页DOM结构解析完成，开始加载内嵌资源时的时间戳。
domContentLoadedEventStart	需要被执行的脚本已经被解析的时间戳。
domContentLoadedEventEnd	需要立即执行的脚本已经被执行的时间戳。
domComplete‍	当前文档解析完成的时间戳。
loadEventStartload	事件被发送时的时间戳，如果这个事件还未被发送，它的值将会是0。
loadEventEnd	load事件结束时的时间戳，如果这个事件还未被发送，它的值将会是0。

通过以上时间点，我们就可以计算出如下的前端性能指标，如：

重定向耗时	redirectEnd - redirectStart
DNS 解析耗时	domainLookupEnd - domainLookupStart
TCP 连接耗时	connectEnd - connectStart
SSL 安全连接耗时	connectEnd - secureConnectionStart
网络请求耗时 (TTFB)	responseStart - requestStart
数据传输耗时	responseEnd - responseStart
DOM 解析耗时	domInteractive - responseEnd
资源加载耗时	loadEventStart - domContentLoadedEventEnd
首包时间	responseStart - domainLookupStart
白屏时间‍	responseEnd - fetchStart
首次可交互时间	domInteractive - fetchStart
DOM Ready 时间	domContentLoadEventEnd - fetchStart
首屏加载时间	domComplete - navigationStart

除performance.timming外，performance API 还有一些方法帮助你获取到更多有用的信息，例如：

• performance.getEntries()

获取到每个资源、xmlhttpRequest的相关参数，例如发起时间，资源地址，耗时等。

点击放大

• performance.getEntriesByType(type)

根据资源类型来查看某种类型的资源耗时等信息。

• performance.getEntriesByName(name, type)

根据名称和资源来源来获取相关信息。

• Performance.now()

可用于记录当前代码执行的时间点，不同于new Date().getTime()。

Date().getTime()	毫秒，当前时间戳,受系统时间的影响，距离 1970 的时间;如：1619014021294
performance.new()	微秒（百万分之一秒）,时间是以恒定速率递增,不受系统程序执行阻塞的影响，相对于 performance.timing.navigationStart(页面初始化) 的时间。如：3956.404999946244

• Performance.mark()

通过在各个地方打点，标记每个点的执行时间点。

3. js错误、vue错误、api错误的采集

通过window.onerror可以捕获JS错误信息：

  /**
   * JS 错误捕获
   * @param {String} msg 错误消息
   * @param {String} url 引发错误的脚本的URL
   * @param {Number} lineNo 发生错误的行号
   * @param {Number} columnNo 发生错误的行的列号
   * @param {Object} error 错误对象
   */
  window.onerror = (msg, url, lineNo, columnNo, error) => {
   console.log(error.stack);
   // do something.....
  } ;

vue错误不能使用window.onerror来捕获，vue提供了Vue.config.errorHandler方法来捕获vue错误，例如：

  /**
   * Vue错误捕获
   * @param {Object} error 错误对象
   */
  Vue.config.errorHandler = (error) => {
    console.log(error);
   // do something.....
  };

如果你使用axios来处理API，在axios发送请求后，使用catch，或在Axios拦截器统一处理，例如：

new Promise((resolve, reject) => {
axios.post(url, data).then((response) => {
}).catch(function(error){
console.log(error);
// do something.....
})
})








// 或在Axios拦截器统一处理
Axios.interceptors.response.use(
  (response) => {
  },
  (error) => {
console.log(error);
// do something.....
  },
);

以上就是关于前端性能监控方面的一些衡量指标、数据采集方法，为下一步的性能优化提供了方向和数据支持。

---

作者简介

何瑞，腾讯AB实验平台前端开发工程师。

---

6月5日，Techo TVP 开发者峰会 ServerlessDays China 2021，即将重磅来袭！

扫码立即参会赢好礼????