这是我参加[第五届青训营]伴学笔记创作活动的第11天
本堂课程知识
- 知道前端监控的意义与前世今生。
- 从用户的视角思考我们监控的性能指标与前端异常给用户带来的影响。
- 学会监听部分性能指标与前端异常，并封装成一个通用的监听器。
- 学会将监听器封装到 sdk 中，以及按需加载和链式调用的一些小技巧。
前端监控
经典面试题： 在浏览器里，从输入URL到页面展示，这中间发生了什么？
前端监控就是尽可能的采集这一过程以及后续用户交互中产出的性能指标与发生的异常事件并上报到平台完成消费。
前端监控的必要性：监测到网页加载速度慢，网页交互卡顿，资源加载失败，网页白屏等问题
前端监控内容
性能指标
web性能标准的诞生
早期网页是纯静态的,但随着Web爆发式发展,页面交互越来越复杂。开发者开始思考如何提高Web性能、改善用户体验。
因此,2010年8月,W3C成立了Web性能工作组,由来自Google 和Microsoft的工程师担任主席,目标是制定衡量Web应用性能的方法和API。
随后,Web性能工作组开始制定一系列Web性能标准,应用到桌面和移动浏览器以及其他环境中,帮助Web开发人员评估和理解应用的性能特征E。
传统的性能指标
两种模型都为传统的且内容相近的，后者相对出现比较晚，为现在浏览器的性能指标模型，但指标较为繁杂，对于开发者和用户都难以理解，即引入以用户为中心的指标
以用户为中心的性能指标
传统的性能指标专注于容易衡量的技术细节,但是很难反映用户真正关心的。如果你仅把加载速度优化的更快,你很快就会发现网站的用户体验依然很差。这就是创建用户为中心的性能指标的原因,它们专注于用户现角下的浏览体验。
所以提出以下的递进式的性能指标
简单理解，是以下的过程：页面是否开始渲染了-内容渲染好了吗-内容是可以交互的吗-用户体验高兴吗
慢慢出现的体验更佳
FID(First Input Delay):测量从用户第一次与页面交互(比如当他们单击链接、点按按钮等等)直到浏览器对交互作出响应,实际能够开始处理事件时处理程序所经过的时间
LCP (Largest Contentful Paint):最大的内容在可视区域内的变得可见的时间点。
LCP 优点:1.容易理解2.给出与FMP相似的结果3.容易计算和上报
TBT(Total Blocking Time):量化主线程在空闲之前的繁忙程度,有助于理解在加载期间,页面无法响应用户输入的时间有多久。
CLS(Cumulative Layout Shift):量化了在页面加载期间,视口中元素的移动程度。点击按钮后有几率因加载广告或图片导致按钮和文本偏移，观感和体感都不太舒服，也可能会有误触。
异常事件
- 静态资源错误
- 请求异常-请求异常=请求响应状态码>=400，对于通过异步请求拉取的静态资源错误也可选择归纳到请求异常
- js错误
- 白屏异常-前面几类异常都可以通过浏览器提供的标准化方法来监听到到,而白屏异常没有标准化的监听方法,所以更考验前端监控开发者的功底。通常我们可以通过判断DOM树的结构来粗略的判断白屏是否发生。
监听到白屏发生后,我们还需要对白屏的发生进行归因。
因为时间原因，用户行为这块不做赘述，课后需自行了解，线上用户的基本行为包括但不限于：访问页面，点击行为，请求接口行为，js报错行为
