Resource Timing bufferFull事件解析与性能数据防丢失

处理Resource Timing的bufferFull事件，核心在于主动的“监听”与“清理”。浏览器资源性能缓冲区容量有限，默认通常仅能保存150条记录。一旦写满，后续资源加载数据将不再被记录，直接导致关键性能指标丢失。这一问题在单页应用或资源密集型页面中尤为突出。

监听 resourcetimingbufferfull 事件

该事件在缓冲区即将溢出时触发，因此必须提前注册监听。最佳实践是在页面脚本的早期阶段（例如在标签内）完成设置：

• 首先，可考虑使用window.performance.setResourceTimingBufferSize(n)主动扩大缓冲区容量，例如设置为250。但需注意，此值并非越大越好，需权衡内存开销。
• 接着，通过performance.onresourcetimingbufferfull = handler或更推荐的addEventListener('resourcetimingbufferfull', handler)方式设置回调函数。后者在兼容性和支持多次绑定方面更具优势。
• 在回调函数中，动作需迅速：立即调用performance.getEntriesByType('resource')提取缓冲区中所有资源记录，然后立即执行performance.clearResourceTimings()清空缓冲区，为后续资源数据腾出空间。

提取并上报资源性能数据

从缓冲区获取的是PerformanceResourceTiming对象，它包含了从DNS查询到资源加载完成的完整阶段耗时。这些原始数据需经结构化处理再上报：

• 进行一轮过滤，排除favicon、Beacon请求等非关键资源，将分析焦点集中在影响首屏渲染和用户交互的JS、CSS、图片及API请求上。
• 计算核心性能指标：包括DNS查询时长（domainLookupEnd - domainLookupStart）、TCP连接耗时、首字节时间TTFB（responseStart - requestStart），以及资源总加载时长（duration）。
• 上报数据时，建议采用navigator.sendBeacon方法。它能确保即使在页面卸载（跳转或关闭）前，性能数据也能可靠发出，避免丢失。

补充兜底策略防漏采

仅靠bufferFull事件监听无法覆盖所有场景，一套稳健的方案还需叠加以下兜底策略：

• 在window.onload或DOMContentLoaded事件触发后，主动调用一次getEntriesByType('resource')，捕获此时所有已加载完成的资源数据。
• 对于动态插入的资源（例如懒加载的图片、异步加载的组件JS），可在资源插入DOM后，通过短暂延时（如setTimeout(..., 100)）再进行采集，以确保浏览器的timing数据已写入缓冲区。
• 同时监控performance.timing中的navigationStart和fetchStart等导航计时点，这有助于识别因跨页面跳转导致的计时上下文重置，从而避免误判白屏或加载异常。

整套逻辑并不复杂，但这些细节最易在开发中被忽略，最终影响性能监控的完整性。