HTML怎么做API响应监控_html API接口响应时间监控【速查】-html教程-PHP中文网

纯前端无法直接监控后端api真实响应时间，因performance api受跨域、cors预检、缓存、service worker等干扰，timing字段常丢失或失真；可靠做法是fetch拦截+date.now()手动计时，并结合服务端注入的x-response-time等header分离网络与服务端耗时。

html怎么做api响应监控_html api接口响应时间监控【速查】

纯前端无法直接监控后端 API 的真实响应时间——浏览器只暴露了「网络层可观测时间」，比如 responseStart 和 responseEnd，但这些值受缓存、代理、跨域限制和 CORS 预检干扰，不能等同于服务端处理耗时。

为什么 performance.getEntriesByType('resource') 不可靠

你常看到的「用 PerformanceResourceTiming 测接口耗时」方案，在真实项目中容易失效：

非同源 API 会丢失大部分 timing 字段（responseStart、connectStart 等返回 0）
CORS 预检请求（OPTIONS）会覆盖主请求的 entry，导致取错对象
Service Worker 拦截后，timing 数据可能被重写或清空
HTTP/2 多路复用下，多个请求共享连接，connectStart 不再对应单次请求

正确做法：只对同源、无预检、未被 SW 拦截的资源使用该 API；其他情况必须依赖服务端注入的自定义 header（如 X-Response-Time）并配合 fetch 拦截解析。

fetch 拦截 + Date.now() 是最稳的前端打点方式

绕过 Performance API 的兼容性陷阱，用原生 fetch 包装器手动计时，可控性强：

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

在 fetch 调用前记录 startTime = Date.now()
在 then 或 catch 中计算 responseTime = Date.now() - startTime
注意排除 304 响应（服务端未返回 body，但浏览器仍算作一次完整 fetch）
避免在 finally 里上报——网络中断时可能 never resolve/reject，造成计时挂起

示例片段：

const monitoredFetch = (url, options = {}) => {
  const startTime = Date.now();
  return fetch(url, options)
    .then(res => {
      const duration = Date.now() - startTime;
      if (res.status !== 304) {
        navigator.sendBeacon('/log', JSON.stringify({ url, duration, status: res.status }));
      }
      return res;
    })
    .catch(err => {
      const duration = Date.now() - startTime;
      navigator.sendBeacon('/log', JSON.stringify({ url, duration, error: err.name }));
      throw err;
    });
};

如何识别“假快”响应（缓存/CDN 干扰）

用户看到的「200ms 响应」可能是 CDN 缓存命中，不代表服务端性能好。需主动区分：

检查响应 header：cf-cache-status（Cloudflare）、x-cache（AWS CloudFront）、age（标准缓存年龄）
服务端需返回 X-Backend-Time 或类似字段，标出真实处理耗时
前端上报时把 cacheStatus 和 backendTime 分开传，否则监控大盘会被缓存数据稀释
不要仅靠 performance.getEntriesByType('resource') 的 duration 判断性能——它包含 DNS、TCP、TLS 全链路，不是后端耗时