Long Tasks API 是浏览器原生性能诊断工具，用于识别主线程上超50ms的任务，依据RAIL模型响应红线；通过PerformanceObserver实时捕获或getEntriesByType('longtask')回溯分析，结合DevTools定位调用栈并针对性优化。
Long Tasks API 是浏览器原生支持的性能诊断工具，专门用于识别主线程上执行时间超过 50ms 的任务。这个阈值不是经验值，而是 RAIL 模型中“响应”阶段的关键红线——超过它，用户就会感知卡顿。识别只是第一步，真正价值在于快速定位源头并落地优化。
用 PerformanceObserver 实时捕获长任务
这是线上监控和开发调试最可靠的方式，能第一时间拿到任务发生时的原始数据：
- 创建 observer 并监听 longtask 类型（注意拼写是
longtask，不是long-task） - 每个 entry 包含
startTime、duration、name和attribution字段；其中name在 iframe 场景下可能为same-origin-ancestor，主文档中常为空，但duration和时间戳始终有效 - 建议在页面加载早期注册（如
<script>内联执行），避免错过首屏关键路径上的长任务 - 上报时可节流处理：比如只上报
duration ≥ 100ms或每分钟最多 3 条，防止日志爆炸
用 performance.getEntriesByType('longtask') 快速回溯
适合本地调试或自动化脚本中做快照分析，不依赖监听时机：
- 该方法只返回已结束且未被浏览器清理的 longtask 条目，调用越早越完整（例如在
window.onload后立刻执行） - 返回数组按
startTime升序排列，可结合用户操作时间（如 click 的event.timeStamp）判断是否相关 - 它不提供调用栈，但能告诉你“什么时间发生了多长的阻塞”，是配合 DevTools 定位的第一步线索
- 注意：
performance.getEntries()不会包含 longtask，必须显式调用getEntriesByType('longtask')
结合 DevTools 定位真实源头
API 提供的是“发生了什么”，DevTools 才能回答“是谁干的”：
- 打开 Chrome DevTools → Performance 标签 → 点击录制 → 复现对应操作 → 停止
- 在 Main 轨道中找宽度 ≥50ms 的连续色块（默认高亮为黄色，带红色三角警告）
- 点击色块，在 Summary 面板查看 Duration 和调用栈；在 Call Tree 中按 Total Time 排序，顶部函数大概率就是罪魁祸首
- 若没看到高亮，检查右上角齿轮图标 → 勾选 Enable long task highlighting；开启 CPU 节流（如 4x slower）有助于放大问题，但非必需
常见优化方向与落地建议
发现长任务后，不能只改一行代码，要匹配其类型选择策略：
-
纯计算型（如大数据过滤、JSON 解析）→ 拆分为小任务，用
setTimeout或requestIdleCallback分批执行 -
DOM 批量操作型（如循环 append 100 个节点）→ 使用
DocumentFragment或createDocument缓存后一次性挂载 -
同步布局强制触发型（如反复读取
offsetTop）→ 缓存值、批量读取，或改用getBoundingClientRect+requestAnimationFrame - 第三方脚本型（如统计 SDK、客服组件）→ 延迟加载、沙箱隔离，或要求其提供异步初始化接口
