这是我参与「第五届青训营 」笔记创作活动的第16天
重点内容
- 前端监控的概念
- 前端监控的性能指标与异常
- 实战:封装用于监听性能指标与前端异常的监听器
- 实战:封装一个有完整上报能力的SDK
为什么我们要聊前端监控
什么是前端监控
在浏览器里,从输入 URL 到页面展示,这中间发生了什么?
前端监控就是尽可能的采集这一过程以及后续用户交互中产出的性能指标与发生的异常事件并上报到平台完成消费。
为什么需要前端监控
- 让我们从用户(浏览网页的人)的视角来抛出一些使用时遇到的问题:
- 让我们再从开发者(开发网页的人)的视角来回答用户抛出的问题:
- 当我们的网页有了前端监控的能力
前端监控通过对页面数据的采集和上报,来帮助开发者更快速地对质量差的页面进行分析与归因。
- 案例分析:监控页面质量为什么那么重要?
- 缤趣(图片社交分享网站)将感知等待时间减少了40%,这将搜索引擎浏览和注册量增加了15%
- COOK(冷冻速食订购网站)将网页平均加载时间减少了850毫秒,从而将转化次数提高了7%,将跳出率降低了7%,并将每个会话的页面增加了10%
- 研究还表明,性能不佳会对业务目标产生负面影响。例如,BBC发现他们的网站加载时间每增加一秒,他们就会失去10%的用户
前端监控到底监控了什么
- 性能指标
- 异常事件
- 用户行为
前端监控的常用性能指标
Web 性能标准的诞生
早期页面是纯静态的,但随着Web爆发式发展,页面交互越来越复杂。开发者开始思考如何提高Web性能、改善用户体验。
因此,2010年8月,W3C成立了Web性能工作组,由来自Google和Microsoft的工程师担任主席,目标是制定衡量Web应用性能的方法和API。
随后,Web性能工作组开始制定一系列Web性能标准,应用到桌面和移动浏览器以及其他环境中,帮助Web开发人员评估和理解应用的性能特征。
传统的性能指标
传统的性能指标主要依赖Navigation Timing 或者Navigation Timing2,通过记录一个文档从发起请求到加载完毕的各阶段的性能耗时,以加载速度来衡量性能
以用户为中心的性能指标
传统的性能指标专注于容易衡量的技术细节,但是它们很难反应出用户所真正关心的是什么。
如果你仅仅是把加载速度优化得更快,你很快就会发现网站的用户体验依然很差。
这就是创建以用户为中心的性能指标的原因,它们专注于用户视角下的浏览体验。
- FP(First Paint):首次渲染的时间点。FP时间点之前,用户看到的都是没有任何内容的白色屏幕。
- FCP(First Contentful Paint):首次有内容渲染的时间点。
- FMP(First Meaningful Paint):首次绘制有意义内容的时间点。
- TTI(Time toInteractive):测量页面从开始加载到主要子资源完成渲染,并能够快速、可靠地响应用户输入所需的时间。
- TTI是反映页面可用性的重要指标。TTI值越小,代表用户可以更早地操作页面,用户体验就更好。
- SI(Speed Index):衡量页面可视区域加载速度,帮助检测页面的加载体验差异。
- A 和 B的首次内容出现和完全加载时间是一样的,但是从用户角度A的体验明显更好。
- FID(First Input Delay):测量用户从第一次与页面交互(比如当他们单击链接、点按按钮等等)直到浏览器对交互作出响应,实际能够开始处理事件时处理程序所经过的时间
- LCP(Largest Contentful Paint):最大的内容在可视区域内变得可见的时间点。
- LCP优点:
-
- 容易理解
-
- 给出与FMP相似的结果
- 3.容易计算和上报
-
-
TBT(Total Blocking Time):量化主线程在空闲之前的繁忙程度,有助于理解在加载期间,页面无法响应用户输入的时间有多久。
-
长任务:如果一个任务在主线程上运行超过50毫秒,那么它就是长任务。超过50ms后的任务耗时,都算作任务的阻塞时间。
-
一个页面的TBT,是从FCP到TTI之间所有长任务的阻塞时间的总和。
-
CLS(Cumulative Layout Shift):量化了在页面加载期间,视口中元素的移动程度。
-
当我们点击按钮时,突然出现了一块内容。无论是以一种增加意外点击几率的方式加载广告,还是在加载图片时文本向下移动,内容的意外移动都会让人非常不舒服。
前端常见异常
静态资源错误
- 静态资源:加载页面所需的html、css和js等文件,以及其他各类多媒体文件,如图片、音频和视频等。
- 静态资源错误:在拉取和加载静态资源的过程中发生了预期之外的错误,如网络异常等,导致静态资源无法正常渲染到页面上。
请求异常
Http 请求状态码分类:
- 100 - 199 :信息响应
- 200 - 299 :成功响应
- 300 - 399 :重定向消息
- 400 - 499 :客户端错误响应
- 500 - 599 :服务端错误响应
请求异常 = 请求响应状态码 >= 400
对于通过异步请求拉取的静态资源错误也可选择归纳到请求异常
- 状态码0:
请求成功率 = 请求成功数 /(请求成功数 + 请求失败数)
JS 错误
在页面运行时发生的JS错误会严重影响页面的正常渲染与交互,是前端监控的重点。
白屏异常
前面几类异常都可以通过浏览器提供的标准化方法来监听到,而白屏异常没有标准化的监听方法,所以更考验前端监控开发者的功底。
通常我们可以通过判断 DOM树的结构来粗略的判断白屏是否发生。
通常导致白屏发生的原因可能有如下几点:
- 发生 JS错误导致关键资源渲染失败
- 请求异常或静态资源加载失败
- 长时间的JS线程繁忙阻塞渲染任务。
实战:监控前端性能与异常
性能指标监控
利用 Performance 和 PerformanceObserver 可以监控到一些标准的渲染性能数据
码上掘金:性能监控实战演练
JS 错误监控
利用 window.addEventListener的 error 和 unhandledrejection 可以监控到全局的js错误
码上掘金:js错误监控实战演练
静态资源错误监控
利用 window.addEventListener 的 error 事件可以监控到静态资源错误,注意要和js error进行区分
码上掘金:静态资源错误监控实战演练
请求异常监控
通过 hook xhr 和 fetch 对象来监听请求时发生的错误
码上掘金:请求异常监控实战演练
实战:封装一个通用的 SDK
前端监控流程概述
SDK主要完成前两步,后两步需要后端服务和平台的支持
数据上报
封装一个用于给监控器上报已收集数据的上报函数
专为前端监控打造的请求函数Navigator.sendBeacon()
按需加载监控能力
我们需要将之前实现的监控器按需加载到SDK中,从而封装成一个完整的SDK 码上掘金:按需加载监控能力实战演练