这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天
前端监控与SDK|青训营笔记
为什么聊前端监控
什么是前端监控
即尽可能的采集这一过程以及后续用户交互中产出的性能指标与发送的异常事件并上报到平台完成消费
为什么需要前监控
前端监控通过对页面数据的采集和上报，来帮助开发者更快速地对质量差的页面进行分析和归因。
前端监控到底监控了什么
- 性能指标
- 异常事件
- 用户行为
前端监控之常用性能指标
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 to interactive) | 测量页面从开始加载到主要子资源完成渲染，并能够快速、可靠地响应用户输入所需时间 |
| TTI | 反映页面可用性的重要指标。TTI值越小，代表用户可以更早地操作页面，用户体验就更好 |
| SI(speed index) | 衡量页面可视区域加载速度，帮助页面的加载体验差异 。A 和 B 的首次内容出现和完全加载时间是一样的，但是从用户角度A的体验明显更好 |
| FID(first input delay) | 测量从用户第一次与页面交互(比如当他们点击链接、点按按钮等等)直到浏览器对交互作出响应，实际能够开始处理事件时处理程序所经过的时间 |
| LCP(largest contentful paint) | 最大的内容在可视区域内变得可见的时间点（最大的内容，例如一篇文章中的一大段文字或产品页面上的一张图片，大概就是让你理解页面内容的最有用的元素） LCP优点： |
| TBT(total blocking time) | 量化主线程在空闲之前的繁忙程度，有助于理解在加载期间，页面无法响应用户输入的时间有多久.一个页面的TBT，是从FCP到TTI之间的所有长任务的阻塞时间的总和 |
| CLS(cumulative layout shift) | 量化了在页面加载期间，视口中元素的移动程度. 当我们点击按钮时，突然出现了一块内容，无论是以一种增加以外点击几率的方式加载广告，还是加载图片时文本向下移动，内容的意外移动都会让人非常不舒服 |
前端监控之常见异常
静态资源错误
静态资源：加载页面所需的html、css和js等文件，以及其他各类多媒体文件，如图片、音频和视频等
加载资源错误：在拉取和加载静态资源的过程中发生了预期之外的错误，如网络异常等，导致静态资源无法正常渲染到页面上
请求异常
请求异常 = 请求响应状态码>= 400 对于通过异步请求拉取的静态资源错误也可选择归纳到请求异常
JS 错误
在页面运行时发生的JS错误会严重影响页面的正常渲染与交互，是前端监控的重点
白屏异常
白屏异常没有标准化的监听方法，更考验前端监控开发者的功底.
通常我们可以判断DOM树的结构来粗略的判断白屏是否发生.
通常导致白屏发生的原因有如下几点：
