前端性能初探
前端监控
提升稳定性，更快的发现异常，定位异常，解决异常，js错误，接口异常，资源异常，白屏等。
关注用户体验，建立性能规范，长期关注优化，页面性能，接口性能，资源加载性能，卡顿监控
了解业务数据，指导产品升级，pv uv 业务数据，行为监控
前端监控的流程
数据采集
pv监控: 页面切换后新的url，页面切换的原因（初始化，spa，hash， history）
js错误: 错误对应的类型，描述，行列号，堆栈，错误发生前的用户交互，错误的上下文
性能监控: 首屏加载各阶段耗时，各性能指标，spa切换耗时，longtash等
请求监控: 请求的路径，状态码，请求头和响应头，请求各阶段的耗时等等
白屏监控: 白屏发生的页面，关联的异常，相关的上下文
静态资源监控，用户行为监控，自定义监控
组件上报
基础信息包装: 页面路由，页面标识，全局context，部署版本，部署环境，网络等
采样逻辑
用户自定义包装逻辑执行: 补充更多的上下文，数据脱敏等
队列暂存，聚合发送
sendBeacon: 在页面关闭的时候发送请求，不阻塞页面的加载
清洗存储
user-agent解析: 浏览器版本，系统版本，机型，设备品牌等
ip解析: 地区，省份，城市，运营商，地理位置等
分类型落表落库
处理js错误，堆栈归一化，堆栈反解析
clickhouse存储
数据消费
总览分析
各功能模块消费视角，多堆分析
单点查询，针对用户全生命周期上报数据的重建展示
数据订阅 实时报警
issue管理，归因分析
前端监控关注点
可交互性: 卡顿监控，请求性能
服务稳定性: 请求成功率 首屏性能
加载速度: 首屏性能
可用性: 渲染错误/白屏 请求错误 js错误 静态资源错误等
业务数据 pv/uv 自定义事件/打点
web性能指标
Navigation Timing
文档导航过程中的完整计时，一个文档从发起请求到加载完毕各阶段的性能耗时
Performance Timeline
提供了获取各种类型的性能时间线条的方法，navigation，resource，paint等性能时间线的方法
resource Timing
提供文档中资源的计时信息
paint timing
记录在页面加载期间的一些关键时间点
long tasks api
检测长任务的存在，长任务会在很长的一段时间内独占ui线程，阻塞其他关键任务的执行，比如响应用户输入
**传统的性能指标主要依赖navigation timages/果页面使用HTTPS,它的值是安全连接握手前的时刻
connectEnd: 当浏览器端完成与服务器建立连接的时刻
responseStart: 当客户端收到从服务器端（或缓存，本地资源）响应回的第一个字节的数据的时刻
responseEnd: 客户端收到从服务器端(或者缓存，本地资源)响应回的最后一个字节的数据的时刻
响应回的最后一个字节的数据的时刻
以用户为中心的性能指标
传统的性能指标专注于衡量技术细节，很难反应出用户真正关心的是什么，创建用户为中心的指标，专注于用户视角下的浏览体验
指标分类
- 发生了吗: FP(first paint) FCP(first contentful paint)
- 内容有用吗: FMP(first meangingful paint) si(speed index)
- 内容可用吗: TTI(time to interactive)
- 令人愉悦吗: FID(first input delay)
first paint: 首次渲染的时间点，fp时间点之前，用户看到的都是没有任何内容的白色屏幕
fist contentful paint: 首次有内容渲染的时间点，在用户访问web网页的过程中，fcp时间点之前，用户看到的都是没有任何实际内容的屏幕，fcp反映当前web页面的网络加载性能情况，页面的dom结构复杂度情况，inline script执行效率的情况，当所有的阶段性能做的非常好的情况下，首次出现内容的情况，当所有的阶段性能做的非常好的情况下，首次出现内容的时间就会越短，用户等待的时间就会越短，流失的概念就会降低
first meaningful paint: 首次绘制有意义内容的时间点，当整体页面的布局和文字内容全部渲染完成后，可以认为是完成了首次内容的绘制，fmp通常被认为是用户获取到了页面主要信息的时刻，也就是说，这个时候用户的需求是得到满足的，所以也会很关注fmp指标
fmp代码实现的原理: 认为dom结构变化的时间点，和与之对应的渲染的时间点近似相同，所以fmp的时间点为dom结构变化最剧烈的时间点，dom结构变化的时间点，可以利用mutationobserver api来获得。 - 利用mutationobserver监听每一次页面整体的dom变化，触发mutationobserver的回调
- 在回调计算出当前dom树的分数，分数变化最剧烈的时刻，就是fmp的时间点
speed index: 衡量页面可视区域加载速度，帮助检测页面的加载体验差异。
time to interactive: 检测页面从开始加载到主要的子资源完成渲染，能够快速的，可靠的响应用户输入所需要的时间。tti反映页面的可用性的重要指标，tti值越小，代表用户可以越早的操作界面，用户体验越好
- tti算法实现
- 首先进行首次内容绘制fcp
- 沿着时间轴正向搜索时长至少为5s的安静窗口，安静窗口: 没有长任务而且不超过两个正在处理的get网络请求
- 沿着时间轴反向搜索安静窗口之前的最后一个长任务，如果没有找到长任务，则会在fcp步骤停止执行
- tti是安静窗口之前最后一个长任务的任务结束时间，如果没有找到长任务，则和tcp值相同
以用户为中心的性能指标
传统的性能指标专注于衡量技术细节，很难反应出用户真正关心的是什么，创建用户为中心的指标，专注于用户视角下的浏览体验
指标分类
- 发生了吗: FP(first paint) FCP(first contentful paint)
- 内容有用吗: FMP(first meangingful paint) si(speed index)
- 内容可用吗: TTI(time to interactive)
- 令人愉悦吗: FID(first input delay)
first paint: 首次渲染的时间点，fp时间点之前，用户看到的都是没有任何内容的白色屏幕
fist contentful paint: 首次有内容渲染的时间点，在用户访问web网页的过程中，fcp时间点之前，用户看到的都是没有任何实际内容的屏幕，fcp反映当前web页面的网络加载性能情况，页面的dom结构复杂度情况，inline script执行效率的情况，当所有的阶段性能做的非常好的情况下，首次出现内容的情况，当所有的阶段性能做的非常好的情况下，首次出现内容的时间就会越短，用户等待的时间就会越短，流失的概念就会降低
first meaningful paint: 首次绘制有意义内容的时间点，当整体页面的布局和文字内容全部渲染完成后，可以认为是完成了首次内容的绘制，fmp通常被认为是用户获取到了页面主要信息的时刻，也就是说，这个时候用户的需求是得到满足的，所以也会很关注fmp指标
fmp代码实现的原理: 认为dom结构变化的时间点，和与之对应的渲染的时间点近似相同，所以fmp的时间点为dom结构变化最剧烈的时间点，dom结构变化的时间点，可以利用mutationobserver api来获得。 - 利用mutationobserver监听每一次页面整体的dom变化，触发mutationobserver的回调
- 在回调计算出当前dom树的分数，分数变化最剧烈的时刻，就是fmp的时间点
speed index: 衡量页面可视区域加载速度，帮助检测页面的加载体验差异。
time to interactive: 检测页面从开始加载到主要的子资源完成渲染，能够快速的，可靠的响应用户输入所需要的时间。tti反映页面的可用性的重要指标，tti值越小，代表用户可以越早的操作界面，用户体验越好
- tti算法实现
- 首先进行首次内容绘制fcp
- 沿着时间轴正向搜索时长至少为5s的安静窗口，安静窗口: 没有长任务而且不超过两个正在处理的get网络请求
- 沿着时间轴反向搜索安静窗口之前的最后一个长任务，如果没有找到长任务，则会在fcp步骤停止执行
- tti是安静窗口之前最后一个长任务的任务结束时间，如果没有找到长任务，则和tcp值相同
first input delay: 测量从用户第一次和页面交互，比如说是单击连接，点按按钮等，浏览器对交互进行响应，实际能够开始处理时间，处理程序所经过的时间
1. fid反应用户对页面交互性和响应性的第一印象，良好的第一印象有助于用户建立对整个引用的良好印象
2. 页面加载阶段，资源的处理任务最重，也容易产生输入延迟，关注fid对提升页面的可交互性有很大的收益
3. fid和页面加载完成之后的input delay具有不同的解决方案，对于fid，一般建议通过code splitting来减少页面加载阶段js的加载，解析和执行时间，页面假爱完成后的input delay，通常是由于开发人员编写不当，引起的js执行时间过长而产生的
增加了三个全新的性能指标，填补了用户体验的空白，LCP(Largest contentful paint) TBT(Total Blocking Time) CLS(cumulative layout shift)
**LCP(largest contentful paint)**最大的内容在可视区域内变得可见的时间点
- LCP 容易理解，给出和fmp相似的结果，容易计算和上报
TBT(total blocking time): 量化主线程在空闲之前的繁忙程序，有助于理解在加载期间，页面无法响应用户的输入的时间有多久
长任务: 如果一个任务在主线程上运行超过50ms，超过50ms后的任务耗时，都算作任务的阻塞时间，一个页面的TBT, 是从FCP到TTI之间的所有长任务的阻塞时间的总和
CLS: 量化了页面在加载的期间，视口中元素的移动程度
如何获取站点的性能指标
web-vitals相关的指标，可以通过chrome插件获取
前端性能优化和案例分析
网络优化
- 开启http/2 关注兼容性的问题，同时做好域名收缩，尽量减少子域，让http2的多路复用发挥作用。在http1中，由于浏览器会存在并发限制，所以会进行一个域名分散。
- 开启brotli压缩 相比于gzip，具有更高的broti压缩
更高的压缩比，更快的压缩性能。 - 善用https 通过有效的优化手段，比如session resume， ocsp stapling等，提高https的性能
- 使用cdn部署静态资源 有效的降低访问延迟，提高可用性
- dns预解析
<link rel="dns-prefetch" href="//cdn.example.com"> - 提前建立网络连接 常用于server api等域名，兼容性更好
<link rel="preconnect" hre"//example.com">
缓存优化
memory cache: chrome缓存的第一道防线
cache api: 更细粒度的手动控制页面资源的缓存策略
http cache: 强缓存和协商缓存
push cache: server push产生的缓存
server