异步请求耗时统计方法详解

本文深入探讨了前端性能监控中异步请求耗时统计的高效与可靠实践，强调优先采用浏览器原生Performance API（如performance.getEntriesByType('resource')和PerformanceObserver）自动采集高精度、全阶段网络耗时，覆盖DNS查询、TCP连接、TTFB、下载等关键指标；同时提供了针对旧浏览器的手动埋点兜底方案，结合requestIdleCallback优化上报时机，并系统性指出需过滤缓存命中、重定向链路、CORS限制及cancel请求等常见干扰因素，最后给出按URL模板、状态码分组聚合、分级上报（关键请求即时报、非关键批量报、异常优先报）的落地建议，兼顾准确性、兼容性与工程健壮性。

前端性能监控中统计异步请求耗时，核心是捕获请求发起和响应完成的时间点，并排除干扰（如缓存、重试、跨域限制）。最可靠的方式不是依赖 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，需在封装的请求层手动埋点。关键点是：避免阻塞主线程、防止重复上报、统一管理请求生命周期：

• 在 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 中，防止监控代码自身报错影响业务。

今天关于《异步请求耗时统计方法详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！