处理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请求等非关键资源，将分析重点聚焦于影响首屏渲染和用户交互的JavaScript、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等导航计时点，这有助于识别因跨页面跳转导致的计时上下文重置，从而避免误判白屏或加载异常。
整套逻辑看似简单，但正是这些细节最容易在开发中被忽略，从而影响性能监控的完整性。
