这是我参与[第五届青训营]笔记创作活动的第十二天
本课堂重点内容:
- 何为前端监控
- 前端监控的常用性能指标
- 前端监控的常见异常
- 监控前端性能与异常
- 封装通用的 sdk
详细知识点介绍:
什么是前端监控:
前端监控就是尽可能的采集这一过程以及后续用户交互中产出的性能指标与发生的异常事件并上报到平台完成消费
为何需要前端监控:
前端监控通过对页面数据的采集和上报,来帮助开发者更快速的对质量差的页面进行分析和归因
前端监控,监控了什么:
- 性能指标
- 异常事件
- 用户行为
以用户为中心的性能指标:
传统的性能指标专注于容易衡量的技术细节,但是它们很难反应出用户所真正关心的是什么。如果仅是把加载速度优化的更快,网站的用户体验依然很差。
这就是创建用户为中心的性能指标的原因,它们专注于用户视角下的浏览体验。
- FP (First Paint): 首次渲染的时间点。FP 时间点之前,用户看到的都是没有任何内容的白色屏幕
- FCP (First Contentful Paint): 首次有内容渲染的时间点
- FMP (First Meaningful Paint): 首次绘制有意义内容的时间点
- TTI (Time to Interactive): 测量页面从开始加载到主要子资源完成渲染,并能够快速、可靠响应用户输入所需的时间
TTI 是反映页面可用性的重要指标。TTI 越小,代表用户可以更早操作页面,用户体验更好。 - FID (First Input Delay): 测量从用户第一次与页面交互(如:单击链接等)直到浏览器对交互作出响应,实际能够开始处理事件时处理程序所经过的时间
- LCP (Largest Contentful Paint):最大的内容在可视区域内变得可见的时间点
- TBT (Total Blocking Time): 量化主线程在空闲之前的繁忙程度,有助于理解在加载期间,页面无法响应用户输入的时间有多久,一个页面的 TBT,是从 FCP —— TTI 之间所有长任务(超过50ms)的阻塞时间的总和
- CLS (Cumulative Layout Shift): 量化了在页面加载期间,视口中元素的移动程度
静态资源错误:
在拉取和加载静态资源的过程中发生预期之外的错误,如网络异常等,导致静态资源无法正常渲染到页面上
请求异常:
请求异常 = 请求响应状态码 >= 400
对于通过异步请求拉去的静态资源错误也可以选择归纳到请求异常
js 错误:
在页面运行时发生的 js 错误会严重影响页面的正常渲染与交互,是前端监控的重点
白屏异常:
白屏异常没有标准化的监听方法,所以更考验前端监控开发者的功力。通常我们通过判断 DOM 树的结构来粗略判断白屏是否发生。
导致白屏发生的原因可能有几点:
- 发生 js 错误导致关键资源渲染失败
- 请求异常或静态资源加载失败
- 长时间的 js 线程繁忙阻塞渲染任务
性能指标监控:
js 错误监控:
静态资源错误监控:
请求异常监控:
实践练习例子:
封装一个通用的 sdk:
专为前端监控打造的请求函数
function createSdk(url: string) {
const monitors: Array<{ name: string, start: Function }> = [];
const sdk = {
url,
report,
loadMonitor,
monitors,
start,
}
function report({ name: string, data: any }) {
// 注意:数据发送前需要先序列化为字符串
navigator.sendBeacon(url, JSON.stringify({ name: string, data: any }));
}
function loadMonitor({ name: string, start: Function }) {
monitors.push({ name: string, start: Function });
// 实现链式调用
return sdk;
}
function start() {
monitors.forEach(m => m.start());
}
return sdk;
}
const sdk = createSdk("111.com");
const jsMonitor = createJsErrorMonitor(sdk.report);
sdk.loadMonitor(jsMonitor).loadMonitor(createPerfMonitor(sdk.report));
sdk.start();
个人课后总结:
前端监控是非常重要的一环,对改善用户体验有重大作用。