这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天 冲！
为什么聊前端监控
什么是前端监控
从浏览器里，从输入URL到页面展示，这中间发生了什么？ 前端监控就是尽可能的采集这一过程以及后续用户交互中产出的性能指标与发生的异常事件并上报到平台完成消费
为什么需要前端监控
前端监控通过对页面数据的采集和上报，来帮助开发者更快速地对质量差的页面进行分析和归因
-
前端监控的重要性
- 缤趣(图片社交分享网站)将感知等待时间减少了40%，这将搜索引擎流量和注册量增加了15%
- COOK(冷冻速食订购网站)将页面平均加载事件减少了850毫秒，从而将转化次数提高了7%，将跳出率降低了7%，从而将每个会话的页面增加了10%
研究还表明，性能不佳会对业务目标产生负面影响。例如：BBC发现他们的网站加载事件每增加1秒，他们就会失去10%的用户
前端监控到底监控了什么
- 性能指标
- 异常事件
- 用户行为
前端监控之常用性能指标
性能标准的诞生
早期网页是纯静态的，但是随着Web爆发式发展，页面交互越来越复杂，开发者开始思考如何提高Web性能，改善用户体验
因此，2010年8月，W3C建立了Web性能工作组，由来自Google和Microsoft的工程师担任主席，目标是指定衡量Web应用性能的方法和API
随后，Web性能工作组开始制定一系列Web性能标准，应用到桌面和移动浏览器以及其他环境中，帮助Web开发人员评估和理解应用的性能特征
传统的性能指标
传统的性能指标主要依赖 Navigation Timing 或者 Navigation Timing 2，通过记录一个文档从发起请求到加载完毕的各阶段的性能耗时，以加载速度来衡量性能。
以用户为中心的性能指标
传统的性能指标专注于容易衡量的技术细节，但是它们很难反应出用户所真正关心的是什么。如果仅仅把加载速度优化的更快，你很快就会发现网站的用户体验依然很差。
这就是创建用户为中心的性能指标的原因，它们专注与用户视角下的浏览体验
-
FP(first paint)：首次渲染的时间点，FP时间点之前，用户看到的都是没有任何内容的白色屏幕
-
FCP(first contentful paint)：首次有内容渲染的时间点
-
FMP(first meaningful paint)：首次绘制有意义内容的时间点
-
TTI(Time to interactive)：测量页面从开始加载到主要子资源完成渲染，并能够快速、可靠地响应用户输入所需时间
- TTI反映页面可用性的重要指标。TTI值越小，代表用户可以更早地操作页面，用户体验就更好
-
SI(speed index)：衡量页面可视区域加载速度，帮助页面的加载体验差异
-
A 和 B 的首次内容出现和完全加载时间是一样的，但是从用户角度A的体验明显更好
-
FID(first input delay)：测量从用户第一次与页面交互(比如当他们点击链接、点按按钮等等)直到浏览器对交互作出响应，实际能够开始处理事件时处理程序所经过的时间
-
LCP(largest contentful paint )：最大的内容在可视区域内变得可见的时间点
-
最大的元素，例如一篇文章中的一大段文字或产品页面上的一张图片，大概就是让你理解页面内容的最有用的元素
-
LCP优点：
- 容易理解
- 给出与FMP相似的结果
- 容易计算和上报
-
TBT(total blocking time)：量化主线程在空闲之前的繁忙程度，有助于理解在加载期间，页面无法响应用户输入的时间有多久
-
长任务：如果一个任务在主线程上运行超过50ms，那么它就是长线程，超过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.addEventLister 和unhandledrejection可以监控到全局的JS错误
静态资源错误监控
利用window.addEventListener 的error事件可以监控到静态资源错误，注意和JS error进行区分
请求异常监控
通过hook xhr 和fetch对象来监听请求时发生的错误
封装一个通用的sdk
前端监控流程概述
sdk主要完成前两步，后两步需要后端服务和平台的支持，其中前面的章节已经完成了数据采集以及简单的数据组装
数据上报
封装一个用于给监控器上报已收集数据的上报函数
专为前端监控打造的请求函数Navigator.sendBeacon()
