HTML本身不支持慢请求监控，需通过JavaScript结合PerformanceObserver监听resource类型条目，或重写fetch/XMLHttpRequest实现主动拦截，且监控脚本须轻量、早初始化、避免干扰性能。
HTML 本身不直接支持“慢请求监控”，真正能捕获慢 HTTP 请求的是运行在浏览器中的 JavaScript，配合 PerformanceObserver 或拦截 wx.request（小程序）、fetch / XMLHttpRequest（Web 页面）等 API。关键不在 HTML 标签，而在 JS 层的监听时机和方式。
用 PerformanceObserver 监控 fetch/xhr 慢请求
现代浏览器中，PerformanceObserver 可监听 "resource" 类型条目，从中筛选出耗时超阈值的请求。但注意：它只记录已完成的请求，无法实时中断或告警。
- 必须在
<head>最开头注册，否则漏掉首屏关键请求（如 CSS、关键 JS 的加载） - 只对同源资源生效；跨域需服务端配
Timing-Allow-Origin: *，否则duration为 0 - 过滤逻辑要写在
observer回调里，示例：
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 1000 && entry.name.startsWith("https://")) {
navigator.sendBeacon("/log", JSON.stringify({
url: entry.name,
duration: entry.duration,
type: entry.initiatorType
}));
}
}
}).observe({ entryTypes: ["resource"] });⚠️ 常见坑：监听 "navigation" 或 "paint" 无法拿到单个请求耗时；"longtask" 是主线程阻塞，不是网络慢。
重写 fetch 和 XMLHttpRequest 实现主动拦截
这是最可控的方式，能捕获所有请求、打点起止时间、判断是否超时，并支持自定义上报逻辑。
立即学习“前端免费学习笔记（深入）”；
-
fetch可直接覆盖全局函数，但要注意保留原生行为（用window.fetch调用） -
XMLHttpRequest需重写open和send，并在onload/onerror中计算耗时 - 必须处理 Promise reject 场景（如网络中断），否则监控会丢失失败请求
- 示例片段（fetch）：
const originalFetch = window.fetch;
window.fetch = function(url, options = {}) {
const start = performance.now();
return originalFetch.apply(this, arguments)
.then(res => {
const end = performance.now();
if (end - start > 2000) {
sendSlowLog({ url, duration: end - start, status: res.status });
}
return res;
})
.catch(err => {
const end = performance.now();
if (end - start > 2000) {
sendSlowLog({ url, duration: end - start, error: err.message });
}
throw err;
});
};⚠️ 注意：若页面用了第三方 SDK（如 Sentry、Fundebug），它们可能已劫持过 fetch，此时需确认执行顺序，避免重复包装或覆盖失效。
微信小程序里用 Fundebug 监控慢 request
小程序环境不支持 PerformanceObserver 和全局 fetch 替换，得依赖 SDK 提供的封装能力。
- Fundebug 插件 1.3.1+ 版本通过
httpTimeout参数开启慢请求捕获，单位毫秒 - 必须在
App()初始化前引入并调用fundebug.init()，否则部分请求无法拦截 - 仅对
wx.request生效，wx.uploadFile、wx.downloadFile不在此监控范围内 - 上报数据含完整 URL 和耗时，但不包含请求体（除非显式开启
monitorHttpData: true）
⚠️ 容易被忽略的一点：小程序开发者工具默认禁用部分监控权限，真机调试时才触发真实上报；且 httpTimeout 设得太低（如 100ms）会导致大量误报，建议从 800ms 起调。
真正难的不是“怎么记下慢请求”，而是确保监控代码自身不拖慢页面——它不能做 DOM 操作、不能发同步 XHR、体积要压到 1.5KB 内，且初始化必须比任何业务 JS 更早。很多团队上线后发现 FCP 变差，最后定位到是监控脚本里一个没删的 console.log 触发了 DevTools 的序列化开销。
