前端性能监控实战：Performance API采集与Core Web Vitals优化

前端性能监控不是上线后看报告，而是在开发阶段就能量化每一个改动。浏览器原生提供的Performance API可以采集页面从导航开始到资源加载完成的全部时间点，配合PerformanceObserver监听关键指标，用很小的成本搭建一套自定义监控。本文用原生API实现LCP、FID/INP、CLS三个Core Web Vitals指标的采集，并说明各自的优化切入点。

Core Web Vitals指标与Performance API对应关系

Google定义的Core Web Vitals有三项：LCP（最大内容绘制，加载性能）、INP（交互到下一次绘制，响应性能）、CLS（累积布局偏移，视觉稳定性）。对应采集方式：

采集这些指标不依赖第三方SDK，全部用浏览器原生API完成。

PerformanceObserver采集LCP与FCP

// LCP 采集：观察最大内容元素
let lcpValue = null;
const lcpObserver = new PerformanceObserver((list) => {
    const entries = list.getEntries();
    const lastEntry = entries[entries.length - 1];
    lcpValue = lastEntry.startTime;
});
lcpObserver.observe({ type: 'largest-contentful-paint', buffered: true });

// FCP 采集
const fcpObserver = new PerformanceObserver((list) => {
    const entries = list.getEntries();
    const fcp = entries[0].startTime;
    reportMetric('fcp', fcp);
});
fcpObserver.observe({ type: 'paint', buffered: true });

LCP对应的是元素加载完成的时刻，优化抓手在首屏资源的加载优先级：给首屏图片加fetchpriority=”high”，延迟加载图用loading=”lazy”，字体用font-display:swap避免阻塞渲染。FCP靠压缩HTML、去掉阻塞渲染的CSS、把JS标签加defer。

INP采集：Event Timing API

INP采集用户所有交互事件的延迟，包含事件处理时长、渲染时间与下次可交互时间。

const inpObserver = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        if (entry.duration > 50) {  // 只上报慢交互
            reportMetric('inp', {
                duration: entry.duration,
                interactionId: entry.interactionId,
                type: entry.name
            });
        }
    }
});
inpObserver.observe({ type: 'event', durationThreshold: 16, buffered: true });

INP优化点：事件处理器里避免同步长任务，把重计算丢到requestIdleCallback或Web Worker；虚拟滚动列表减少DOM节点；input切换时用content-visibility跳过视口外渲染。

CLS采集与布局偏移检测

let clsValue = 0;
const clsObserver = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        if (!entry.hadRecentInput) {
            clsValue += entry.value;
        }
    }
});
clsObserver.observe({ type: 'layout-shift', buffered: true });

CLS的根因是图片/广告/字体加载后插入元素导致页面跳动。优化手段：图片和视频容器预留宽高比（aspect-ratio），字体用size-adjust避免FOIT/FOUT，动态内容（弹窗、轮播）在固定容器里渲染，避免在文档流中插入。

真实用户监控数据上报设计

前端监控采集到的数据要上报到服务端才能指导优化。上报设计：按页面会话为粒度，页面隐藏或unload时把指标一次性批量POST，用navigator.sendBeacon保证页面关闭时请求能送达。

function reportOnHidden() {
    const data = {
        url: location.href,
        lcp: lcpValue,
        fcp: fcpValue,
        inp: inpValue,
        cls: clsValue,
        ua: navigator.userAgent,
        timestamp: Date.now()
    };
    // 页面隐藏时用 sendBeacon 保证送达
    if (navigator.sendBeacon) {
        navigator.sendBeacon('/metrics', new Blob([JSON.stringify(data)],
            { type: 'application/json' }));
    } else {
        fetch('/metrics', { method: 'POST', body: JSON.stringify(data),
            keepalive: true });
    }
}
document.addEventListener('visibilitychange', () => {
    if (document.visibilityState === 'hidden') sendOnHidden();
});

服务端把指标按页面、浏览器版本、网络类型（effectiveConnectionType）分桶，对比优化前后百分位（P75/P95）变化。本地验证用Lighthouse跑基准，上线后用真实数据验证，两条路径都要。

自定义性能监控与RUM的差异

这套方案是RUM（真实用户监控）的简易实现。相比全量采集，开发团队建议按一定比例采样（比如5%），数据量可控，又能覆盖真实网络环境。与Sentry、datadog等商业方案的差异在于数据资产留在自己手里，可以自由关联业务字段（用户ID、渠道、版本）。落到生产环境后，把指标变化接入告警，超过阈值自动通知，性能劣化在用户投诉前就能发现。

性能优化围绕三个指标展开，每个指标对应可执行的优化项。按这套采集体系落地，每次发版都能量化前后端改动对体验的影响，避免凭感觉优化。