performance api 通过 getentriesbytype 和 performanceobserver 可可靠获取 fcp、lcp、cls 等 web vitals 指标；用户行为埋点应聚焦可见性、路由、核心交互等可归因事件；上报优先用 sendbeacon 批量异步发送，避免阻塞。
怎么用 Performance API 获取真实页面加载性能数据？
浏览器原生的 Performance API 是获取首屏时间、FCP、LCP、CLS 等指标最可靠的方式，不需要第三方 SDK 就能拿到符合 Web Vitals 标准的数据。
-
performance.getEntriesByType('navigation')返回页面导航记录，loadEventEnd - startTime是完整加载耗时 -
performance.getEntriesByType('paint')可取到first-contentful-paint和largest-contentful-paint -
performance.getEntriesByType('layout-shift')拿到所有 CLS 计算所需的 layout shift 条目，需手动累加value - 注意：部分条目（如 LCP）可能延迟触发，建议用
PerformanceObserver监听，而非一次性读取
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.name === 'largest-contentful-paint') {
console.log('LCP:', entry.startTime);
}
}
});
observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'paint'] });用户行为埋点该监听哪些事件？怎么避免漏报和重复？
关键不是“全量监听”，而是聚焦业务可归因的行为路径：页面可见性变化、路由跳转、核心按钮点击、表单提交、错误发生。盲目监听 click 会导致大量噪声和性能损耗。
- 用
document.addEventListener('visibilitychange')判断页面是否真正被用户看到（排除预加载、后台标签页） - SPA 路由变化不能只靠 URL 变更，要结合框架提供的钩子（如 React Router 的
useLocation、Vue Router 的router.afterEach） - 按钮点击优先用事件委托 +
data-track属性标记，避免每个按钮单独绑定 - 防抖
beforeunload和pagehide事件上报，防止因页面快速关闭导致日志丢失
如何把性能和行为数据发出去而不影响用户体验？
上报本身不能成为性能瓶颈。不要用 fetch 或 XMLHttpRequest 同步发，也不要在主线程密集拼接日志对象。
- 优先用
navigator.sendBeacon()：它异步、不阻塞卸载、支持跨域，且在页面关闭前仍能发出请求 - 日志聚合后批量发送，比如每 5 秒或积满 10 条再上报，减少请求数量
- 上报前做简单采样（如
Math.random() ），高流量站点必须控制量级 - 避免在
requestIdleCallback中处理复杂序列化——它本就不可靠，低版本 Safari 不支持，且空闲时间可能根本没触发
function sendLog(data) {
const blob = new Blob([JSON.stringify(data)], { type: 'application/json' });
navigator.sendBeacon('/log', blob);
}为什么你拿到的 FCP 总是比 Lighthouse 低？
这不是代码问题，而是测量环境差异。Lighthouse 在干净、可控、无扩展干扰的 Headless Chrome 中运行；而真实用户环境有广告脚本、A/B 测试 SDK、浏览器插件注入等干扰因素。
立即学习“Java免费学习笔记（深入）”；
- 真实 FCP 偏低常见于：首屏内容被懒加载遮罩覆盖、字体未就绪导致文字重绘、CDN 缓存失效引发资源重拉
- 别直接对比两组数字，应关注趋势：比如某次发版后 FCP P75 下降 300ms，才说明真有问题
- 服务端渲染（SSR）页面要注意：若 hydration 完成前用户已交互，
PerformanceObserver可能错过早期 paint 条目，需配合performance.timing回退兼容
最常被忽略的是 layout shift 的累积计算逻辑——它不是单次值，而是整个生命周期内所有 layout-shift 条目的 value 累加，且只计入 hadRecentInput 为 false 的条目。漏掉这个判断，统计出的 CLS 就完全失真。
