Performance API 是现代前端性能诊断的起点和事实标准，覆盖页面加载到视觉渲染全链路，基于高精度单调时钟；推荐用 PerformanceObserver 监听 largest-contentful-paint、first-input、layout-shift 等关键指标，并结合 resource 条目与 longtask 分析网络、JS 阻塞及布局偏移根因；上报应延后聚合，避免干扰关键路径。
Performance API 是浏览器原生提供的性能观测基础设施，不是辅助工具，而是现代前端性能诊断的起点和事实标准。它能覆盖从页面加载、资源请求、脚本执行、用户交互到视觉渲染的完整链路，且所有时间戳均基于高精度单调时钟（performance.timeOrigin），避免系统时钟漂移干扰。
核心指标采集：用 PerformanceObserver 监听关键事件
现代应用应弃用已废弃的 performance.timing，改用 PerformanceObserver 主动监听异步生成的性能条目：
-
largest-contentful-paint：获取主内容绘制完成时间，判断首屏渲染是否达标（≤2.5s） -
first-input：捕获首次点击/输入的延迟，反映主线程响应能力（≤100ms） -
layout-shift：持续收集布局偏移帧，计算累积值（CLS ≤0.1） -
navigation和resource类型条目可手动触发getEntriesByType()补充分析
const obs = new PerformanceObserver(list => {
list.getEntries().forEach(entry => {
if (entry.entryType === 'largest-contentful-paint') {
console.log('LCP:', entry.startTime);
}
});
});
obs.observe({ entryTypes: ['largest-contentful-paint', 'first-input', 'layout-shift'] });
资源级深度分析：定位慢请求与网络瓶颈performance.getEntriesByType('resource') 返回每个资源（JS/CSS/图片/字体/API）的完整生命周期耗时：
-
startTime到responseEnd：总网络耗时 -
domainLookupStart与domainLookupEnd：DNS 查询是否过长（>20ms 需优化） -
connectStart与secureConnectionStart：TCP/TLS 握手是否拖慢首字节（TTFB） -
duration：资源整体加载时间，结合initiatorType可区分是 script 还是 img 触发
对慢资源，可进一步检查 nextHopProtocol（是否启用 HTTP/2 或 QUIC）、transferSize（是否压缩不足）、encodedBodySize（是否未启用 Brotli）。
渲染与交互协同诊断：不只是看数字，要看上下文
单纯 LCP 数值低不代表体验好——需结合 longtask 条目判断主线程是否被 JS 长任务阻塞；
FID 偏高时，应同步查看 first-input 的 processingStart 与 processingEnd 差值，并比对 longtask 是否正在执行；
CLS 异常上升，要筛选 layout-shift 条目中 hadRecentInput 为 false 的记录，确认是否由无用户操作下的异步插入（如广告、第三方 widget）引发。
上报策略：轻量、延后、聚合
- 不在
DOMContentLoaded立即上报，避免干扰关键路径；推荐在window.addEventListener('load', ...)后加setTimeout(..., 0)延迟发送 - 对
layout-shift等高频条目，服务端应支持流式聚合（如每 5 秒合并一次 CLS）而非逐条接收 - 上报字段至少包含：
entryType、name、startTime、value（或duration）、navigationType（来自performance.navigation.type）、UA 与设备类型
不复杂但容易忽略
