节流上报是前端性能监控中平衡数据完整性与系统开销的关键手段，通过时间窗口+数量阈值双控、差异化处理指标、轻量聚合脱敏等策略实现高效可靠上报。
节流上报是前端性能监控中平衡数据完整性与系统开销的关键手段。长任务、FP、LCP 等指标可能高频触发，若每次事件都立即上报，会引发请求风暴、增加服务器压力，甚至拖慢页面本身。节流不是简单“少报”，而是有策略地聚合、延迟、去重后发送。
为什么需要节流上报
直接监听 PerformanceObserver 并实时调用 fetch 发送日志，容易导致： • 多个长任务在 1 秒内连续触发，产生数十次小请求 • 页面卸载前集中上报，触发浏览器限流或失败 • 同一用户短时间内重复上报相似指标（如多次路由切换触发相同 LCP） 节流能有效降低请求数量、减少主线程干扰、提升上报成功率。
用时间窗口 + 数量阈值做双控节流
推荐组合方式：每 5 秒或积满 10 条性能记录，触发一次批量上报。避免纯时间驱动（可能漏报）或纯数量驱动（低流量页面长期不发）。
- 维护一个缓存队列（如 const queue = []），每次 PerformanceObserver 回调中 push 新 entry
- 启动一个定时器（setInterval），每 5000ms 检查队列长度
- 若队列非空，取出全部条目，调用 navigator.sendBeacon 批量发送，再清空队列
- 同时监听 pagehide 或 beforeunload，强制清空并立即上报剩余数据
对不同指标做差异化节流
并非所有性能数据都适合同一套节流逻辑：
- 严重卡顿（duration ≥ 200ms 的 longtask）：可立即上报，不节流——这类任务大概率已影响用户操作
- Web Vitals（FCP/LCP/CLS）：每个页面生命周期只上报一次，无需节流，但需防重复（如 SPA 中多次导航）
- 高频 longtask（50–200ms）：按上述双控节流，同时记录出现频次和平均耗时，而非逐条上报
- 内存指标（performance.memory）：每 30 秒采样一次，节流周期拉长，避免噪声干扰
上报前做轻量聚合与脱敏
节流不只是“延后发”，更是“ smarter 发”：
立即学习“Java免费学习笔记（深入）”；
- 将同源 iframe 的多个 longtask 按 attribution 分组，统计各 iframe 的总阻塞时长
- 对相同 name（如 'self'）的 longtask，合并为一条：{ name: 'self', count: 8, avgDuration: 76.3, maxDuration: 192 }
- 剔除敏感字段（如完整 URL、stack trace），保留可定位问题的最小信息集
- 添加采样标识（如 sampleRate: 0.1），高流量站点默认 10% 上报，避免数据过载
