前端性能监控：web-vitals

web-vitals库：官方推荐的标准化测量工具

要准确采集Web Vitals指标，最可靠的方案是使用Google官方维护的web-vitals开源库。这个轻量级库完全基于浏览器原生的PerformanceObserver API实现，测量结果与Chrome浏览器、PageSpeed Insights、Search Console等官方工具的数据完全对齐，是目前行业内的事实标准。

核心指标

LCP（最大内容绘制） ：衡量页面加载速度，理想值≤2.5秒，2.5-4秒为需改进，超过4秒则表现较差；
INP（交互到下次绘制延迟） ：衡量全页面生命周期的交互响应能力，理想值≤200毫秒，200-500毫秒为需改进，超过500毫秒则表现较差；
CLS（累积布局偏移） ：衡量页面视觉稳定性，理想值≤0.1，0.1-0.25为需改进，超过0.25则表现较差；

设计细节

低侵入性：库本身体积不到2KB，不会给页面增加额外的性能负担；
缓冲机制：通过开启PerformanceObserver的buffered标志，即使库加载时机较晚，也能捕获到页面早期发生的性能事件，避免丢失首屏关键数据；
模块化设计：支持按需导入所需指标的测量函数，进一步减少打包体积；
版本迭代 ：从v3版本开始，核心测量函数从getXXX()重命名为onXXX()，更准确地表达了"监听指标变化并触发回调"的语义，同时官方会向后兼容旧命名直到v4版本。

实际使用

js 复制代码

import { onLCP, onINP, onCLS } from 'web-vitals';

// 监听LCP指标
onLCP((metric) => {
  console.log('LCP值:', metric.value, 'ms');
  // 可将数据上报到自己的性能监控平台
});

// 监听INP指标
onINP((metric) => {
  console.log('INP值:', metric.value, 'ms');
});

// 监听CLS指标
onCLS((metric) => {
  console.log('CLS值:', metric.value);
});

对于需要深度排查问题的场景，还可以使用带归因分析的扩展模块，直接获取指标异常的根因信息：

js 复制代码

import { onLCP } from 'web-vitals/attribution';
onLCP((metric) => {
  console.log('LCP异常元素:', metric.attribution.element);
  console.log('资源加载延迟:', metric.attribution.resourceLoadDelay);
});

这套归因能力可以直接定位到"哪个元素导致LCP过高"，"哪个资源阻塞了渲染"，大幅降低性能瓶颈的排查成本。

如何优化指标

LCP如何优化

首屏最大图片已转 WebP/AVIF 格式，完成无损压缩；
首屏核心资源已配置 <link rel="preload"> 并标记高优先级；
服务器响应时间控制在 800ms 以内，静态资源接入 CDN；
首屏 JS/CSS 已完成 Tree Shaking，移除未使用冗余代码；
浏览器缓存策略已配置，重复访问无需重新加载核心资源；
不要把首页设计得特别复杂，突出重点内容即可；
使用SSR技术，直接渲染HTML。

INP如何优化

所有超过 50ms 的长任务已拆分，非紧急逻辑移至空闲时段执行；
第三方统计、广告等非核心脚本已设置 defer 或页面 onLoad 后动态加载；
页面冗余事件监听已清理，无重复绑定的无效回调；
数据量超 100 条的长列表已接入虚拟滚动，同时渲染 DOM 数控制在 50 以内。

CLS如何优化

所有图片、视频、iframe 已设置宽高属性，预留占位区域；
动态广告、弹窗组件已提前设置固定尺寸容器，无突然插入的内容；
页面交互优化，减少页面元素跳来跳去的设计；
所有懒加载模块已配套等大占位图，资源加载后不会触发布局偏移。

业务场景

编辑富文本，得到一篇文章或者通知的业务

糟糕的代码设计：进入一个Vue的路由页面，URL上携带文章id，然后去请求得到富文本的内容，用v-html插入页面中。

问题以及解决办法：

文章是一个访问量较大的页面，我们每次进这个页面都需要去请求富文本内容并且插入到页面，LCP数据会很糟糕，并且内容无法缓存。推荐使用SSR的方式，或者服务器直接生成HTML文件，用OSS的方式去访问，这样就可以使用HTTP的缓存了。
文章里面的图片、动态模块，我们需要去做懒加载和占位处理。图片如果不处理的话，在我们浏览文章时，突然加载出一张图片，把文章内容顶走了，这个用户体验会非常差，CLS数据也会很差。

菜单、模块自定义设置的业务

合理的交互设计：支付宝首页服务的功能，我们在添加、删除或者对常用应用进行拖动排序的时候，发现这些都是纯前端的行为，只有在最终点击保存按钮的时候，才会把最终的结果提交到服务端。

糟糕的交互设计：同样的业务场景，有些设计师是这样设计的：点击添加、删除按钮或者拖动排序完成时，立刻生效。对于开发来说，需要在点击按钮的时候调用三个接口：保存接口、查询已添加、查询未添加。

问题：显然，第二种设计方式，每次操作都要调用三个接口，必然不会流畅，INP数据很差。

总结

Web Vitals的本质不是一套用来应付搜索引擎的评分规则，而是一套以用户感知为核心的设计思想。很多时候我们不需要追求极致的数字，而是要在业务功能和体验之间找到平衡：优先优化用户最常接触的核心路径，把资源投入到能真正提升用户体验的地方。