性能监控代码必须轻量异步，避免主线程重计算和高频读取；优先采集navigation、paint、LCP、longtask等核心指标，用PerformanceObserver替代轮询，上报采用sendBeacon并最小化数据。
性能监控代码本身不能拖慢页面——它得比页面快，才配叫“监控”。关键在于采集逻辑要轻量、异步、有节制，避免在主线程做重计算、高频读取或同步上报。
只采集真正需要的指标
别一股脑调用 performance.getEntriesByType() 拉取全部资源。每次调用都会触发内部遍历，大量数据会带来内存与时间开销。应按需筛选：
- 聚焦核心类型：优先查
'navigation'（1次）、'paint'（首屏相关）、'largest-contentful-paint'（LCP）、'longtask'（卡顿根源） - 第三方脚本排查时，再针对性查
'resource'，并立即过滤：initiatorType === 'script' && !name.includes(yourDomain) - 避免在
requestIdleCallback或滚动监听里反复调用，一次采集足矣
用 PerformanceObserver 替代轮询式 getEntriesByType
PerformanceObserver 是浏览器原生的异步监听机制，不阻塞渲染，且只在数据就绪时触发回调。相比手动定时轮询，它更精准、更省资源：
- 注册一次即可持续接收新条目，比如监听 LCP 出现：
new PerformanceObserver(() => { /* 处理LCP */ }).observe({entryTypes: ['largest-contentful-paint']}) - 避免在
load或DOMContentLoaded后立刻批量读取所有 entry——此时数据可能未完全就绪，反而触发强制重排或延迟解析 - 对
'longtask'类型必须提前启用缓冲区：performance.setResourceTimingBufferSize(200)，否则 Observer 可能收不到
上报过程必须脱离主线程
数据收集完，上报动作最易反噬性能。同步 fetch 或 XMLHttpRequest 会阻塞，而 sendBeacon 是唯一可靠选择：
- 使用
navigator.sendBeacon(url, data)：它在页面卸载前异步发出，不等待响应，不影响跳转或关闭 - 上报前做最小化处理：只传关键字段（如
name、startTime、duration），不传完整PerformanceEntry对象 - 启用采样：对非核心用户或低价值页面，用
Math.random() 控制仅 5% 上报，大幅降低请求压力
打点与测量要克制，避免污染真实行为
自己加的 performance.mark() 和 performance.measure() 本身不耗时，但滥用会干扰分析、增加内存负担：
- 每个业务模块限 2–3 个关键 mark（如
'cart-open-start'、'cart-render-end'），不为每一步操作都打点 - 避免在循环或高频事件（如
mousemove）中调用mark，极易堆积上千条无意义记录 - measure 计算建议延后到空闲时段执行，或用
queueMicrotask包裹，不挤占渲染帧
