resource timing 的 bufferfull 事件需主动监听并清空缓冲区，防止性能数据丢失；浏览器默认缓冲区仅150条，应早期注册事件、扩容缓冲区、及时提取并上报关键资源耗时，辅以 onload 和动态资源兜底采集。
解析 Resource Timing 的 bufferFull 事件，核心是主动监听并及时清空缓冲区，避免新资源记录被丢弃。浏览器默认的资源时间缓冲区容量有限（通常为150条），一旦写满，后续资源加载将不再被记录——这会导致关键性能数据丢失，尤其在单页应用或资源密集型页面中尤为明显。
监听 resourcetimingbufferfull 事件
该事件在缓冲区即将溢出时触发，必须提前注册监听，且建议在脚本早期（如 中）执行：
- 使用
window.performance.setResourceTimingBufferSize(n)主动扩大缓冲区（例如设为 250），但不能无限增大，需权衡内存开销 - 通过
performance.onresourcetimingbufferfull = handler设置回调，或更推荐的addEventListener('resourcetimingbufferfull', handler)方式（兼容性更好、支持多次绑定） - 回调中应立即调用
performance.getEntriesByType('resource')提取当前全部资源记录，再调用performance.clearResourceTimings()清空缓冲区，为后续资源腾出空间
提取并上报资源性能数据
获取到的 PerformanceResourceTiming 对象包含完整阶段耗时（如 connectStart、responseEnd、duration 等），需结构化处理后再上报：
- 过滤掉非关键资源（如 favicon、beacon 请求），聚焦 JS/CSS/图片/API 等影响首屏和交互的资源
- 计算关键指标：DNS 查询时长（
domainLookupEnd - domainLookupStart）、TCP 连接耗时、TTFB（responseStart - requestStart）、资源总加载时长（duration） - 上报建议采用
navigator.sendBeacon，确保页面卸载前也能发出数据，避免因跳转或关闭导致丢失
补充兜底策略防漏采
仅靠 bufferFull 监听不足以覆盖所有场景，还需叠加其他机制：
- 在
window.onload或DOMContentLoaded后主动调用一次getEntriesByType('resource')，捕获已加载资源 - 对动态插入的资源（如懒加载图片、异步组件 JS），在插入后短延时（如
setTimeout(..., 100)）再采集，确保 timing 数据已写入缓冲区 - 监控
performance.timing中的navigationStart和fetchStart，识别跨页面跳转导致的 timing 上下文重置，避免误判白屏或加载异常
不复杂但容易忽略
