LongTasksAPI如何检测页面卡顿任务

Long Tasks API 并非“卡顿检测神器”，它仅能捕获主线程上持续≥50ms的任务，而用户真实感知的卡顿（如点击无响应、页面停滞超1秒、帧率骤降）往往需结合耗时阈值（如≥1000ms）、帧间隔异常、输入延迟等多维指标交叉分析；该API在Safari中完全缺失、attribution信息常为空、无法识别连续短任务组合导致的累积卡顿，且不揭示具体执行逻辑——真正落地时，必须用PerformanceObserver尽早监听、辅以requestAnimationFrame监控帧率、上报时携带name与startTime，并最终依赖DevTools性能面板或手动打点才能定位根因，否则线上埋点极易误报、漏报、难排查。

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 内处理输入”，但实际用户是否感知卡顿，取决于上下文：

• 一个 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 执行还是渲染阻塞

最麻烦的一点：API 只告诉你“有长任务”，但从不告诉你“它干了什么”。想定位具体函数，还得结合 console.time() 手动打点，或用 Chrome DevTools 的 Performance 面板录制 —— 这才是真正落地时绕不开的环节。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~