最推荐使用浏览器原生 performance api 自动采集 ajax 耗时，精度高且覆盖 dns、tcp、ttfb、下载等各阶段；仅在 ie 等旧环境退化为请求封装层手动打点，并注意 timing-allow-origin 配置以保障跨域资源数据完整性。
记录 Ajax 请求耗时并上报前端性能监控平台，最推荐的方式是优先使用浏览器原生的 Performance API 自动采集，它精度高、无需手动干预、能获取完整阶段耗时（DNS、TCP、TTFB、下载等）。只有在不支持该 API 的旧环境（如 IE）中，才退回到封装层手动打点。
用 PerformanceObserver 自动捕获 fetch/XHR 耗时
现代浏览器对每个 fetch 或 XMLHttpRequest 发起的网络请求都会自动生成一条 resource 类型性能条目，只要满足同源或服务端返回了 Timing-Allow-Origin 响应头，就能拿到完整时间字段：
-
entry.duration：总耗时（从请求发起至响应体接收完毕） -
entry.responseStart - entry.requestStart：TTFB（含服务端处理） -
entry.connectEnd - entry.connectStart：TCP + TLS 时间 -
entry.responseEnd - entry.responseStart：响应体下载时间
监听示例：
const observer = new PerformanceObserver(list => {<br> list.getEntries().forEach(entry => {<br> if (entry.entryType === 'resource' && entry.initiatorType === 'fetch') {<br> reportToMonitor({<br> url: entry.name,<br> duration: entry.duration,<br> ttfb: entry.responseStart - entry.requestStart,<br> status: 200 // 可结合 fetch 的 response.status 补充<br> });<br> }<br> });<br>});<br>observer.observe({ entryTypes: ['resource'] });
兼容旧浏览器：在请求封装层手动埋点
若需支持 IE 或部分低版本安卓 WebView，应在统一的请求方法（如 request() 函数）中手动记录时间：
- 调用前用
performance.now()记录起点 - 在
.then()和.catch()中统一计算耗时并触发上报 - 避免直接用
setTimeout上报，改用requestIdleCallback（或降级为setTimeout(..., 0)）延迟执行，防止阻塞渲染 - 过滤掉
aborted、canceled或 304 缓存响应，避免干扰统计
上报策略要兼顾可靠性和性能
上报不是越快越好，关键是在不影响用户体验的前提下确保数据不丢失：
- 非关键指标（如普通接口耗时）走批量聚合 + 节流，比如每 10 秒或每 20 条合并发送一次
- 严重错误或超慢请求（如 >5s）立即上报，便于告警
- 页面即将卸载时（
beforeunload或visibilitychange隐藏），用navigator.sendBeacon()发送剩余日志，避免丢失 - 上报地址建议走独立子域名（如
log.yoursite.com），避免与主站资源竞争连接数
注意跨域资源的数据完整性
如果 Ajax 请求目标是第三方接口或 CDN 资源，默认拿不到详细阶段耗时（如 TTFB、TCP），浏览器会将这些字段置为 0。解决办法是让服务端响应头中添加：
Timing-Allow-Origin: * 或 Timing-Allow-Origin: https://yourdomain.com
否则即使用了 Performance API，也只能拿到 duration 这一个值，失去深度分析能力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
