前端性能监控异步请求耗时应优先使用Performance API自动采集，通过performance.getEntriesByType('resource')获取完整阶段耗时；兼容旧浏览器需手动埋点并用requestIdleCallback延迟上报；须过滤缓存、重定向、CORS限制及cancel请求等干扰。
前端性能监控中统计异步请求耗时，核心是捕获请求发起和响应完成的时间点，并排除干扰（如缓存、重试、跨域限制）。最可靠的方式不是依赖 XMLHttpRequest 或 fetch 的手动打点，而是利用浏览器原生的 Performance API，尤其是 performance.getEntriesByType('resource') 和 navigation 类型的指标。
用 Performance API 自动采集网络请求耗时
现代浏览器对每个资源加载（包括 fetch、XMLHttpRequest、图片、脚本等）都会自动记录性能条目。只要请求满足同源或启用了 Timing-Allow-Origin 响应头，就能获取完整的阶段耗时：
- connectStart → connectEnd：TCP 连接建立时间（含 TLS 握手）
- requestStart → responseEnd：实际网络请求耗时（含发送、服务端处理、接收）
- duration：总耗时（从 fetch/XHR 发起时刻到响应体接收完毕，精度可达微秒）
示例：监听新资源并过滤 fetch 请求
function monitorFetchDuration() {
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach(entry => {
if (entry.entryType === 'resource' &&
entry.name.startsWith('https://') &&
entry.initiatorType === 'fetch') {
console.log({
url: entry.name,
duration: entry.duration, // 总耗时（ms）
dns: entry.domainLookupEnd - entry.domainLookupStart,
tcp: entry.connectEnd - entry.connectStart,
ttfb: entry.responseStart - entry.requestStart,
download: entry.responseEnd - entry.responseStart
});
}
});
});
observer.observe({ entryTypes: ['resource'] });
}
monitorFetchDuration();兼容性兜底：手动打点 + requestIdleCallback 优化上报
旧版浏览器（如 IE）不支持 PerformanceObserver，需在封装的请求层手动埋点。关键点是：避免阻塞主线程、防止重复上报、统一管理请求生命周期：
立即学习“Java免费学习笔记（深入）”；
- 在
fetch调用前记录start = performance.now() - 在
.then()和.catch()中计算耗时并上报，确保无论成功失败都采集 - 使用
requestIdleCallback（或降级为setTimeout(..., 0)）延迟上报，避免影响渲染
注意：不要在 XMLHttpRequest.onreadystatechange 中多次打点（如 readyState === 2 不代表已发请求），应以 send() 调用为起点、load 或 error 事件为终点。
规避常见误差来源
真实场景中以下情况会导致统计失真，需主动识别和过滤：
-
HTTP 缓存命中：
transferSize === 0表示未走网络，此时duration反映的是本地读取延迟，不应计入“网络耗时” -
重定向链路：一个 fetch 可能触发多次跳转，
performance.getEntriesByName(url)返回多个条目，应取最后一个（最终目标） -
CORS 资源无完整 timing：若服务端未返回
Timing-Allow-Origin: *，多数阶段字段为 0，只能依赖duration（该值仍可用） -
请求被 cancel：检查
entry.duration > 0且entry.name存在，避免上报无效条目
聚合与上报建议
单次请求耗时意义有限，应按 URL 模板（如 /api/user/:id）、HTTP 方法、状态码分组，计算 P50/P90/P99 和错误率。上报策略推荐：
- 首屏关键请求（如登录、首页数据）立即上报
- 非关键请求聚合后每 10–30 秒批量上报一次，减少请求数
- 异常耗时（如 > 5s）或失败请求优先单独上报，带堆栈与设备信息
不复杂但容易忽略：所有打点逻辑必须包裹在 try/catch 中，防止监控代码自身报错影响业务。
