我们日常工作中总会提到性能优化，这个工作在汇报中或者用户视角当中是没有非常显著的变化的，但这个工作对我们的产品而言是及其重要的，为了具像化我们的工作成果，我们提出对应指标来具像化工作成果。可以使用web-vitals（原理PerformanceObserver）和chrome浏览器提供的performance来做衡量哦～
核心网络指标
FP（First Paint）首次绘制（仅页面开始加载时间，并非可见）
LCP（Largest Contentful Paint）视口中可见的最大图片或文本块 相对于用户首次导航到网页的呈现时间
对比FCP而言只关注绘制主要内容，更有针对性，FCP是关注所有内容的绘制
注意内容
- 尽量将值控制在2.5秒以内，最好衡量网页加载的第75个百分位。
- img元素，第一帧呈现用GIF或动画PNG等动画内容，此类文件内容较大的元素
- svg元素，内部含有image等需加载的元素
- video元素，系统会使用视频海报图片的加载时间或第一帧显示时间为准
- 带有url()函数加载（非css渐变的元素）的背景图
- 包含文本节点或其他内嵌级文本元素字元素的块级元素
- 透明度为0的元素，用户不可见但也有消耗
- 覆盖整个视口的元素（被视为背景而非内容）
- 占位符图片，无法反应网页实际内容
- 注意：为了降低计算和调度新的性能条目的性能开销，对元素的大小或位置所做的更改不会生成新的 LCP 候选版本。系统只会考虑元素的
初始尺寸和在视口中的位置。也就是说，系统可能不会报告最初在屏幕外呈现后又在屏幕上过渡的图片。这也意味着，最初在视口中渲染但后来被下推，而不会显示在视图之外的元素仍会报告其初始视口内尺寸。
报告LCP
目前网页的加载都是分阶段进行的加载，所以网页的最大元素kennel发生变化，就会记录变化后的最大元素进行汇报
我们可以看看对应的过程操作：
- 浏览器绘制完第一帧，分派
largest-contentful-paint类型的PerformanceEntry,标识最大内容元素 - 渲染完成后读帧，当最大内容元素发生变化，再次分派
PerformanceEntry - 注意对于安全考虑，缺少
Timing-Allow-Origin标头的跨源图片，系统不会公开渲染时间戳，仅可查看加载时间，此时所查看的Web API报告可能LCP早于FCP
可优化点
- 示例：一个网站的某一分类界面，优化前 LCP 为 4 秒，通过优化图片大小、懒加载非关键内容等方式，将 LCP 降低到 2 秒以内。
-
调整资源加载顺序，减少渲染阻塞页面资源的加载
-
使用link（会阻塞渲染） src等资源的加载，使用rel属性，使文件可被并行或预先加载，减少阻塞情况
-
图片压缩减少加载时长
-
懒加载非关键内容，使LCP计算窗口内的最大元素
INP（Interaction to Next Paint） 记录用户于网页进行互动的延迟时间，并报告（几乎所有）互动所低于的单个值，越低越好
这里大部分的高值消费在交互网络的行为，需要等待网络响应后反馈视图，这里INP记录的即此时反馈视图的时间，一般建议做好超时设置并长任务加好loading。
计算详情
- 使用鼠标点击
- 点按带有触摸屏的设备
- 按实体键盘或屏幕键盘的某个健
- 记录从输入延迟开始，到运行事件处理脚本所需的时间，再到浏览器绘制下一帧的所有互动，即交互后找到脚本执行的时间
可优化点
- 减少js获取元素后执行事件的操作
- 减少事件绑定，利用事件委托
- 减少eventbus的使用（过量元素的绑定，不是不用）
CLS（Cumulative Layout Shift）累计布局偏移
当视口可见元素在两帧内起始位置发生更改，就会报告
layout-shift条目，影响比例计算为影响比例（总体占视口的比例）* 距离比例（元素相对视口移动的距离 = 布局偏移得分 即CLS。
可优化点
- 做好动画和过渡，减少用户的错误操作发生情况
- 做好占位
其他指标
FCP(First Contentful Paint) 首次内容绘制
用于衡量用户感知的加载速度，从用户输入地址访问到网页内容反馈到界面上（可见）的时间，越快越好。
注意
- FCP 包括前一页面的所有卸载时间、连接设置时间、重定向时间和首字节时间 (TTFB)
- 于LCP不同的是FCP关注内容呈现，只要有呈现即可，而LCP是主要的最大内容被加载完到界面之上
- 报告记录是
first-contentful-paint，可在PerformanceObserver来监听
改进方向
- 消除阻塞渲染资源，link在body上，script在body下
- 减少css大小，移除未使用css，加快绘制速度
- 减小js的代码，使用chunk，缩减非必要的js使用，移除未使用的js
- 调整资源加载顺序，先连接首屏加载所需要的源
- 缩短服务器响应用时（TTFB），使用海外加速等
- 减少重定向界面的使用
- 预加载迷钥请求
- 减少负荷加载
- 使用缓存（eg. pwa）
- 减少过大规模的dom（分页）
- 减少关键请求的深度
- 减少请求数量（bff）等
TTFB 第一个字节加载时间，和服务器响应用时有关
计算内容
- 重定向时间
- service worker启动时间
- DNS查询
- 链接和TLS（协议）协商
- 请求，response end之前
优化点
- 减少文件体积
- 使用缓存
- 提高server-timing
- 拆分请求，加快响应速度
- 减少重定向界面的可能等
FID（First Input Delay） 首次互动输入延迟
和INP有一定相似，但INP记录每次，而FID记录首次的页面交互到浏览器的响应，可衡量可交互性，一般建议控制在100ms以内==》first-input，优化同理INP
FPS（Frames per Second） 帧率，持续时间（每秒画面更新次数） cmd+shift+p打开控制板进行查询(requestAnimationFrame可用此进行监，PerformanceFrameTiming也可但兼容性不好)
FPS是指页面在每秒钟内渲染的帧数，即每秒钟刷新的次数。它衡量的是页面的流畅度和动画效果
可以通过监测页面的渲染性能并计算平均帧率来获取。
优化点
- 其实每帧的渲染次数主要是靠浏览器的能力和电脑的配置来决定的，但是我们的过多的重绘重排会导致帧渲染消耗过高影响我们的帧绘制，从而降低FPS，所以我们可以减少重绘重排，使用BFC，使用canvas等GPU绘制方式
FMP（First Meaningful Paint）从页面开始加载到首次绘制页面主要内容的时间间隔。
和LCP，FCP有一定关联，计算页面首次绘制主要内容的时间
优化点
- 使用HTTP2等多路复用的推送技术，加快首屏渲染主要内容的加载
- 使用CDN外链（因为有缓存）
TBT（Total Blocking Time）总阻塞时间（渲染和执行时间）
和FCP有一定关系，。会衡量FCP后主线程的被阻塞时间以阻止输入响应的总时间
注意
- 如果有长任务（即在主线程上运行超过 50 毫秒的任务），主线程就会被视为“阻塞”。因为此帧操作中无法中断正在执行的任务，一般现在每帧可操作时长67ms（最新的chrome）
优化点
- 减少三方代码对当前界面的影响
- 缩减js执行时长
- 减少主线程工作
- 减少请求数量及大小
TTI 可交互时间（渲染空闲时间）
可交互时间 (TTI) 对离群网络请求和耗时较长的任务过于敏感，导致该指标出现较大的变化。TTI 已作为指标从 Lighthouse 10 中移除
参考
- web.dev
- 个人累积
over
