这是我参与「第五届青训营 」笔记创作活动的第17天
一、本堂课重点内容:
- 开篇:为什么我们要聊前端监控?
- 概述:前端监控之常用性能指标
- 概述:前端监控之前端常见异常
- 小试牛刀:监控前端性能与异常
- 渐入佳境:封装一个通用的SDK
- 课后探索:让你的SDK更健壮
二、详细知识点介绍:
2.1. 开篇:为什么我们要聊前端监控?
从一个常见的前端面试题聊起:在浏览器里从输入URL到页面展示,这中间发生了什么?
前端监控就是尽可能的采集这一过程以及后续用户交互中产出的性能指标与发生的异常事件并上报到平台完成消费。
前端监控通过对页面数据的采集和上报,来帮周开发者更快速地对质量差的页面进行分析与归因。
监控是提高故障处理能力和保障服务质量必需的一环,它需要负责的内容包括:及时上报错误、收集有效信息、提供故障排查依据。
- 及时上报错误:发生线上问题后,经由运营或者产品反馈到开发人员,其中流转过程可能是几分钟甚至几十分钟,这段时间可能直接导致公司的经济损失。如果有一个监控系统,在线上出现问题时,监控系统能够第一时间报警,并且通知到开发人员,那开发人员就可以第一时间修复上线,使公司损失最小化。
- 收集有效信息:特别是移动时代,定位一个问题时,需要很多用户信息(如用户手机版本、网络情况、操作流程等)。如果没有监控数据,往往只能靠猜,又或是来回找产品运营甚至出现问题的用户去沟通定位,会花费大量的时间。假如监控系统里记录了设备信息、错误发生时的场景信息和用户的操作流程,我们就可以直接根据这些信息进行问题定位,在最短时间内完成故障修复,减小问题的影响面。
- 提供故障排查依据:监控前端SDK所上报的错误信息和其它的记录信息,其最终目的都是作为我们排查故障的依据,为我们保障服务提供坚实的依靠。
前端监控到底监控了什么?
2.2. 概述:前端监控之常用性能指标
传统性能指标主要依赖Navigation Timing或者Navigation Timing 2,通过记录一个文档从发起请求到加载完毕的各阶段的性能耗时,以加载速度来衡量性能。
以用户为中心的性能指标:
- FP:首屏渲染的时间点,FP时间点之前,用户看到的都是没有任何信息的白屏。
- FCP:首次有内容渲染的时间点。
- FMP:首次绘制有意义内容的时间点。
- TTI:测量页面从开始加载到主要子资源完成渲染,并能够快速、可靠的响应用户输入所需的时间。TTI反映页面可用性的重要指标,TTI值越小,代表用户可以更早的操作页面,用户体验就更好。
- SI:衡量页面可视区域加载速度,帮助检测页面的加载体验差异。
- FID:测量从用户第一次与页面交互直到浏览器对交互做出响应,实际能够处理事件时处理程序所经过的时间。
- LCP:最大的内容在可视区域内变的可见的时间点。
- TBT:量化主线程在空闲之前的繁忙时间程度,有助于理解在加载时间,页面无法响应用户输入的时间有多久。
- CLS:量化了在页面加载期间,视口中元素的移动速度。
2.3. 概述:前端监控之前端常见异常
静态资源错误:
请求异常:
Http 请求状态码分类:
100- 199 -- 信息响应
200-299 -- 成功响应
300-399 -- 重定向消息
400-499 -- 客户端错误响应
500-599 -- 服务端错误响应
请求异常 = 请求响应状态码>=400
对于通过异步请求拉取的静态资源错误也可选择归纳到请求异常
请求异常:
JS错误:
白屏异常:
三、实践练习例子:
3.1. 小试牛刀:监控前端性能与异常
四、课后个人总结:
更加深入的了解了前端监控的知识。
五、引用参考: