这是我参与「第五届青训营 」伴学笔记创作活动的第25天,昨天学习了前端监控SDK开发的相关知识,今天通过实战演练,对相关内容进行了简单地整理。
什么是前端监控?
前端监控就是尽可能的采集从输入URL到页面展示这一过程以及后续用户交互中产出的性能指标与发生的异常事件并上报到平台完成消费。
为什么需要前端监控?
必要性:
从用户(浏览网页的人)的视角:
- 网页打开速度慢或出现白屏
- 网页非常卡顿
- 图片无法正常展示
- 页面无法正常加载
从开发者(开发网页的人)的视角解答:
- 打开慢 → 页面某个关键资源渲染太慢
- 交互卡顿 → 页面同步计算任务太重,阻塞渲染
- 资源加载失败 → 客户端网络状态差或上游服务节点异常
- 页面白屏 → 页面脚本执行失败,关键资源加载失败,请求失败等
前端监控通过页面数据的采集和上报,来帮助开发者更快速地对质量差的页面进行分析与归因。
重要性:
- 利于增加流量
- 能够提高转化率和留存量
监控了什么?
1、性能指标 2、异常事件 3、用户行为
前端监控常用性能指标
传统性能指标
依赖Navigation Timing或者Navigation Timing 2,通过记录一个文档从发起请求到加载完毕的各种阶段的性能耗时,以加载速度来衡量性能。
以用户为中心的性能指标
传统性能指标专注于容易衡量的技术细节,但是很难反映用户所真正关心的是什么。而以用户为中心的性能指标,专注于用户视角下的浏览体验。
-
FP(First Paint)首次渲染时间点。FP时间点之前,用户看到的都是没有任何内容的白屏。
-
FCP(First Contentful Paint)首次有内容渲染时间点。
-
FMP(First Meaningful Paint)首次绘制有意义内容的时间点,但存在的问题是非标准化且难以在浏览器之间统一实现。
-
TTI(Time to Interactive)反映页面可用性的重要指标。
-
SI(Speed Index)测量页面可视区域加载速度。
-
FID(First Input Delay), 首次输入延迟,记录在 FCP 和 TTI 之间用户首次与页面交互时响应的延迟。
-
LCP (Largest Contentful Paint) 是一个以用户为中心的性能指标,可以测试用户感知到的页面加载速度。
LCP优点:
- 容易理解
- 给出与FMP相似的结果
- 容易计算和上报
-
TBT(Total Blocking Time) 总阻塞时间。测量First Contentful Paint 首次内容绘制 (FCP)与Time to Interactive 可交互时间 (TTI)之间的总时间。
-
CLS(Cumulative Layout Shift)累计布局偏移,是指网页布局在加载期间的偏移量。
前端监控异常
静态资源错误
在拉取和加载静态资源的过程中发生了预期之外的错误,如网络异常等,导致静态资源无法正常渲染到页面上。
请求异常
HTTP请求状态码分类
| 100 - 199 | 信息响应 |
| 200 - 299 | 重定向消息 |
| 300 - 399 | 成功响应 |
| 400 - 499 | 客户端错误响应 |
| 500 - 599 | 服务端错误响应 |
| 请求异常 = 请求响应状态码 >= 400 |
对于通过异步请求拉取的静态资源错误也可选择归纳到请求异常
状态码为0:
- 访问了一个本地文件,xhr去模拟了网络请求,但是并没有真的去访问远程服务器,状态码为0
- 访问了远程资源,但是跨域了,状态码也是0
JS异常
在页面运行时发生的JS错误会严重影响页面的正常渲染和交互,是前端监控的重点。
白屏异常
白屏没有标准化的监听方法通常通过判断DOM树的结构判断白屏是否发生。
监听到白屏发生后还需要对白屏的发生进行归因:
- 发生JS错误导致关键资源渲染失败
- 请求异常或静态资源加载失败
- 长时间的JS线程繁忙阻塞渲染任务