必须用PerformanceObserver订阅longtask类型并在<head>内联脚本中注册且启用buffered:true，否则首屏长任务漏报；需提取startTime、duration等字段关联用户操作定位真实瓶颈，避免误将longtask等同于JS执行慢。
要实时捕获并监控长任务，必须用 PerformanceObserver 订阅 longtask 类型，并在页面早期（最好在 <head> 内联脚本中）完成注册，否则启动前的长任务将无法捕获。
注册 observer 必须带 buffered: true
长任务可能发生在页面加载初期，甚至 DOM 构建前。不启用 buffered: true，observer 就无法读取已发生的条目，导致首屏卡顿完全漏报。
- 注册代码需放在
<head>最顶部的内联<script>中，不能等DOMContentLoaded或任何异步时机 - 必须监听
longtask类型，其他类型（如paint、resource）无法替代 -
observe({ entryTypes: ['longtask'], buffered: true })是最小必要配置
过滤和上报关键字段
每个 longtask 条目包含开始时间、持续时长、影响的帧数等信息，但不提供函数名或调用栈。需提取核心字段用于归因和告警。
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 重点关注
entry.duration > 50的条目（RAIL 模型中判定为阻塞级任务） - 记录
entry.startTime和entry.duration，用于与用户行为（如聚焦编辑器、点击按钮）做时间对齐 - 可结合
entry.attribution?.containerType判断是否来自 script、style 或 iframe，辅助定位问题来源
关联用户操作定位真实瓶颈
单独看 longtask 只知道“卡了”，但不知道“为什么卡”或“影响了谁”。需主动打点建立上下文。
立即学习“前端免费学习笔记（深入）”；
- 在关键交互前打标记，例如用户点击按钮时
performance.mark('btn-click-start') - 若发现
longtask的startTime落在某次标记后 100ms 内，就可认定该操作被此长任务拖慢 - 对富文本编辑器等复杂场景，可在
beforeinput或compositionend前后打点，再比对 nearby longtask
避免常见误用
很多团队误以为 longtask 是“JS 执行慢”的直接证据，其实它反映的是主线程被连续占用 >50ms，原因可能是 JS、样式计算、布局、渲染任一环节。
- 不要只上报
duration，忽略startTime—— 时间戳才能对齐业务逻辑 - 不要在 longtask 回调里执行耗时操作（如发送上报请求），可能引发连锁长任务
- 不要依赖
getEntriesByType('longtask')替代 observer —— 它只能查已注册后的条目，且无 buffered 支持
