怎么通过HTML的Long Tasks API检测导致页面卡顿的长时间执行任务-html教程-PHP中文网

Long Tasks API 仅记录≥50ms的主线程任务，不能直接检测用户感知的卡顿；需结合≥1s耗时、帧率丢失或输入延迟等指标综合判断，且存在Safari不支持、attribution为空、漏报连续短任务等局限。

怎么通过html的long tasks api检测导致页面卡顿的长时间执行任务

Long Tasks API 本身不能直接“检测卡顿”，它只记录 ≥50ms 的主线程任务；真正卡顿（如用户明显感知的停滞）往往需要结合 1s+ 耗时或帧率丢失来判断。

用 `PerformanceObserver` 监听 longtask 类型条目

这是最标准、最及时的方式，适用于现代浏览器（Chrome 70+、Edge 79+、Firefox 117+ 支持，Safari 尚未支持）。它能捕获运行中产生的 long task，而不是等页面卸载后才查。

PerformanceObserver 必须在页面早期（如中）注册，否则会错过首屏关键 long task
监听类型必须是 "longtask"，不是 "long-task" 或其他拼写
回调中拿到的 entry 是 PerformanceLongTaskTiming 实例，关键字段是 duration、startTime 和 attribution
注意：attribution 在跨域 iframe 或某些 script 加载方式下可能为空，此时只能靠 name 粗略判断来源（如 "self" 表示主文档 JS）

const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    if (entry.duration >= 1000) {
      console.warn('疑似卡顿任务', {
        duration: entry.duration,
        startTime: entry.startTime,
        name: entry.name,
        attribution: entry.attribution
      });
    }
  });
});
observer.observe({ entryTypes: ['longtask'] });

用 `performance.getEntriesByType('longtask')` 查已发生的记录

适合调试阶段快速查看当前页面已积累的 long task，但无法捕获后续新任务——它只返回过去已结束且未被清除的条目。

调用时机很重要：放在 window.onload 后能拿到渲染阶段的 long task；放在 setTimeout(..., 0) 里可能漏掉 microtask 后立即触发的 long task
返回数组按 startTime 升序排列，但不保证连续——浏览器可能因内存策略丢弃旧条目
该方法不触发任何回调，纯被动查询，适合配合 DevTools 手动分析，不适合线上埋点

const longTasks = performance.getEntriesByType('longtask');
longTasks.forEach(task => {
  console.log(`耗时 ${task.duration.toFixed(1)}ms`, task.name);
});

为什么单看 `duration ≥ 50ms` 不等于卡顿？

RAIL 模型说“50ms 内处理输入”，但实际用户是否感知卡顿，取决于上下文：

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

一个 duration=60ms 的 self 任务发生在用户点击按钮瞬间 → 很可能造成点击无反馈，属于真实卡顿
一个 duration=80ms 的 rendering 任务发生在空闲期（比如用户刚滚动完）→ 用户无感知，不应报警
多个 duration=45ms 的任务连续执行（如循环处理 20 个 DOM 节点），总耗时 >200ms → longtask API 根本不会记录其中任何一个，但用户已明显卡顿

所以仅依赖 longtask 条目会漏报。真正要定位卡顿根源，必须把 longtask 和 requestAnimationFrame 帧间隔、event.timestamp 输入延迟、甚至 InteractionId（Chrome 120+）关联起来看。

容易忽略的兼容性与采样陷阱

这个 API 是实验性的，生产环境使用需兜底：

检查 window.PerformanceObserver 和 PerformanceObserver.supportedEntryTypes 是否包含 "longtask"，否则降级为 requestAnimationFrame 间隔检测
部分 Android WebView（尤其旧版）完全不支持 longtask，且不抛错，静默失败
即使支持，attribution 字段在非 Chrome 内核中基本为空，导致无法定位到具体 script 文件或行号
上报时别只传 duration，至少带上 name 和 startTime，否则线上排查时根本分不清是 JS 执行还是渲染阻塞