直接用 PerformanceObserver 监听 longtask 类型可捕获导致卡顿和掉帧的主线程阻塞任务，浏览器将超 50ms 的 JS 任务标记为长任务，需在 <head> 开头注册并启用 buffered: true，结合 requestAnimationFrame 交叉验证帧率，轻量上报适配生产环境。
直接用 PerformanceObserver 监听 longtask 类型，就能捕获导致卡顿和掉帧的主线程阻塞任务。浏览器把执行超 50ms 的 JS 任务标记为长任务，这类任务会挤占渲染时间，使帧率下降甚至丢帧。
启用 longtask 监听并确保不漏数据
必须在 <head> 最开头立即注册监听器，否则首屏关键长任务可能已发生却未被捕获：
- 使用
buffered: true，可读取注册前已发生的长任务记录 - 只监听
longtask，避免混入resource或mark等高开销类型 - 检查
PerformanceObserver和longtask是否受支持，降级逻辑要简洁
从长任务数据定位卡顿源头
每个 entry 提供三个关键字段，帮助缩小问题范围：
- duration：真实耗时（毫秒），超过 50ms 即触发卡顿风险
-
startTime：高精度时间戳，可对齐用户操作（如点击、滚动）或
performance.mark()打点 - attribution（部分浏览器支持）：指出任务来自主文档、iframe 还是 Web Worker，辅助识别第三方脚本或嵌套内容影响
结合帧率表现做交叉验证
单靠 longtask 只能知道“哪里卡”，但无法确认是否真掉帧。建议同步用 requestAnimationFrame 检测实际帧间隔：
立即学习“前端免费学习笔记（深入）”；
- 记录连续两次
requestAnimationFrame的时间差，若持续 ≥ 16.7ms（即低于 60fps）且与某 longtask 时间重叠，基本可断定该任务引发掉帧 - 避免仅依赖 FPS 阈值（如“连续 3 帧低于 20fps”），因低端设备刷新率本就低；应以 50ms 长任务为锚点，再看其是否造成后续帧延迟
轻量上报与生产环境适配
监控本身不能成为新瓶颈：
- 开发阶段可直接
console.warn输出，生产环境改用navigator.sendBeacon异步发送 - 节流汇总：每 30 秒聚合成一批，减少请求频次；单次 payload 控制在 1.5KB 内
- 移动端或低端设备可降级——比如只上报
duration > 100ms的严重长任务，或关闭 attribution 收集
