长任务是指执行时间超过 50 毫秒 的主线程任务。浏览器的主线程负责处理 JavaScript 执行、DOM 渲染、用户交互等关键操作。当某个任务占用主线程超过 50ms 时，就会阻塞后续任务，导致页面响应延迟、动画掉帧、滚动卡顿等问题。

50ms 的阈值源于 RAIL 性能模型——为了保持 60fps 的流畅体验，每帧预算约 16ms，而 50ms 是一个关键的感知阈值，超过此时间用户就能明显感受到延迟。

PerformanceObserver 是浏览器提供的性能监测接口，可以异步订阅特定类型的性能条目。对于长任务检测：

1. 创建观察器实例，指定监听 type: 'longtask'
2. 设置 buffered: true 可获取缓冲区中已记录的历史长任务
3. 每当主线程完成一个超过 50ms 的任务，回调函数就会收到对应的 PerformanceEntry 对象
4. 每个条目包含 duration（精确耗时）、startTime、attribution（归属信息）等字段

与轮询方式不同，PerformanceObserver 是事件驱动的，性能开销极低，适合生产环境使用。

• 交互延迟：点击按钮、输入文字等操作响应迟钝，用户感觉"卡顿"
• 动画掉帧：CSS 动画、Canvas 渲染出现明显的跳帧和闪烁
• 滚动不流畅：页面滚动时出现"橡皮筋"效果或顿挫感
• INP 指标恶化：Interaction to Next Paint（Google 核心 Web 指标之一）直接受长任务影响
• 可访问性问题：屏幕阅读器等辅助工具响应变慢

通过监控和优化长任务，可以显著提升页面的交互响应性。

以下是一些优化策略：

• 任务分片：使用 requestAnimationFrame、setTimeout 或 scheduler.postTask() 将大任务拆分为多个小任务
• Web Worker：将计算密集型逻辑移至后台线程，避免阻塞主线程
• 懒加载与代码分割：减少初始 JavaScript 体积，按需加载模块
• 防抖与节流：对高频事件（scroll、resize、input）进行频率控制
• 优化 DOM 操作：使用 DocumentFragment 或虚拟 DOM 批量更新，减少回流和重绘
• 延迟非关键任务：利用 requestIdleCallback 在浏览器空闲时执行低优先级工作

持续监控长任务是性能优化的第一步——你无法优化你无法测量的东西。

Long Tasks API 的浏览器支持情况：

• Chrome 58+：完全支持 ✅
• Edge 79+：完全支持 ✅
• Opera 45+：完全支持 ✅
• Samsung Internet：支持 ✅
• Firefox：不支持 ❌（截至 2025 年仍在考虑中）
• Safari：不支持 ❌

在生产环境中使用时，建议进行特性检测并提供降级方案。本工具会自动检测浏览器兼容性并给出提示。

Total Blocking Time (TBT) 是 Lighthouse 和 Web Vitals 中的关键指标，它直接基于长任务计算：

TBT = Σ (每个长任务的 duration - 50ms)

即：将所有超过 50ms 的任务的超出部分累加起来。例如：

• 一个 70ms 的长任务，贡献 20ms 的阻塞时间
• 一个 120ms 的长任务，贡献 70ms 的阻塞时间
• 一个 40ms 的任务（不是长任务），贡献 0ms

TBT 越低，页面的交互响应性越好。通过本工具监控长任务，你可以直接定位导致高 TBT 的代码段。