Long Tasks API 仅记录≥50ms的主线程任务，不能直接检测用户感知的卡顿；需结合≥1s耗时、帧率丢失或输入延迟等指标综合判断，且存在Safari不支持、attribution为空、漏报连续短任务等局限。
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 内处理输入”，但实际用户是否感知卡顿，取决于上下文：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 一个
duration=60ms的self任务发生在用户点击按钮瞬间 → 很可能造成点击无反馈，属于真实卡顿 - 一个
duration=80ms的rendering任务发生在空闲期（比如用户刚滚动完）→ 用户无感知，不应报警 - 多个
duration=45ms的任务连续执行（如循环处理 20 个 DOM 节点），总耗时 >200ms →longtaskAPI 根本不会记录其中任何一个，但用户已明显卡顿
所以仅依赖 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 面板录制 —— 这才是真正落地时绕不开的环节。
