Web Performance Long Tasks 的定位与拆分

我排查前端卡顿时，最先关心的不是“页面加载了多少 KB”，而是主线程有没有被一段连续工作占住。只要一个任务连续运行达到 50ms，用户的点击、滚动和绘制就可能排队；这类任务就是 Web Performance Long Tasks。定位时先记录它何时发生、持续多久、属于哪个浏览上下文，再回到代码中拆分真正占 CPU 的同步工作。

本文只讲 Long Tasks 的观察、归因和拆分。Long Tasks API 的官方资料地址：https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongTaskTiming；它在 MDN 上标记为有限可用，生产接入前要保留能力检测和降级路径。

先把 Long Task 和普通慢操作区分开

Long Task 指主 UI 线程上一段不间断、持续至少 50ms 的任务。它可能来自 JavaScript，也可能包含浏览器在同一任务阶段执行的解析、样式或布局工作。常见表现是点击延迟、滚动不跟手、动画跳帧，或者页面看起来已经出现内容但仍然不能及时响应。

“一次函数调用很慢”和“页面出现 Long Task”不是完全相同的说法：函数可能被分散在多个任务中，也可能在一个任务里叠加 DOM 读写、脚本执行和布局计算。先抓到长任务，再结合 Performance 面板或业务标记定位来源，判断会更稳。

用 PerformanceObserver 先记录持续时间和归属

浏览器支持 Long Tasks 时，可以观察 longtask 条目。不要直接假设 API 存在，先检查 PerformanceObserver.supportedEntryTypes；不支持时保留空实现或改用开发阶段的 Performance 面板，不要因为没有条目就把页面判断为“没有卡顿”。

function observeLongTasks(onEntry) {
  // Long Tasks API 不是所有浏览器都可用，先做能力检测。
  const supported = PerformanceObserver.supportedEntryTypes || [];
  if (!supported.includes('longtask')) return () => {};

  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // duration 是任务持续时间，name 和 attribution 用来缩小归属范围。
      onEntry({
        startTime: entry.startTime,
        duration: entry.duration,
        name: entry.name,
        attribution: entry.attribution?.map((item) => ({
          name: item.name,
          containerType: item.containerType,
          containerSrc: item.containerSrc,
        })) ?? [],
      });
    }
  });

  // buffered=true 让观察器也能接收创建前已被浏览器缓冲的条目。
  observer.observe({ type: 'longtask', buffered: true });
  // 页面卸载或组件销毁时解除观察，避免保留回调引用。
  return () => observer.disconnect();
}

const stop = observeLongTasks((entry) => {
  // 线上上报时只保留必要字段，避免把完整 URL 或敏感参数带走。
  console.info('long task', entry.duration, entry.name, entry.attribution);
});

duration 是第一层证据；name 描述最小归属范围，attribution 可能提供容器类型、来源和容器标识等信息。它们适合回答“哪一类上下文占住了主线程”，但不能替代源码级分析。要知道具体函数，仍需用 Performance 面板录制并展开主线程活动，或在可疑业务段加自己的 performance.mark()。

把一次长任务追到可修改的工作单元

我通常按三层看结果。第一层是任务本身：持续时间是否明显超过 50ms，发生在首屏、输入响应还是后台刷新。第二层是归属：name 是否指向当前页面，attribution 是否提示 iframe 或其它浏览上下文。第三层才是代码：是大 JSON 解析、批量 DOM 创建、排序计算，还是第三方脚本和布局连锁。

如果条目总是出现在同一个业务动作附近，可以给动作加测量标记，把“用户触发到结果提交”的时间与 Long Task 时间线对齐。不要只按总耗时排序；一段 120ms 的初始化工作和四段 55ms 的输入处理，对交互体验的风险并不一样。

用批次和让出主线程拆分同步工作

拆分不是简单地把一个函数改名，而是让浏览器在两批工作之间获得执行输入、样式和绘制的机会。下面以处理数组为例：每批只处理固定数量，批次结束后通过 setTimeout 排入新的任务。批次大小要结合设备和实际数据调整，不能把 50ms 当作所有环境都适用的精确预算。

function yieldToMain() {
  return new Promise((resolve) => {
    // 让当前任务结束，把后续批次放到新的任务中。
    setTimeout(resolve, 0);
  });
}

async function processInChunks(items, handle, chunkSize = 100) {
  for (let offset = 0; offset 

批次拆分后，单个任务变短并不等于总工作量变少；它主要改善可响应性。若工作是纯计算且可以脱离 DOM，就应进一步考虑 Web Worker；若每批都触发同步布局，仍要调整读写顺序，否则只是把多次布局开销分散到更多任务里。

用同一观察口判断拆分是否有效

调整前后保持相同的用户动作、数据量和观察方式，比较 Long Task 的数量、最长持续时间以及发生位置。支持 Long Tasks API 的浏览器才会产生这类条目，因此要把“没有条目”和“没有支持”区分开。开发阶段可以结合 Performance 面板确认主线程活动；线上上报则只保留能支持决策的最小字段。

• 如果最长任务下降且输入期间不再出现长条目，说明让出主线程的方向有效。
• 如果条目数量增加但每条很短，要结合交互延迟判断，不能只追求数量变少。
• 如果拆分后仍有长任务，检查单批处理量、DOM 读写和第三方脚本，而不是继续盲目减小批次。

常见问题

Long Task 一定是 JavaScript 写错了吗？ 不一定。它反映的是主线程连续被占用，原因可能包括脚本、布局、样式或其它浏览器工作，需要结合主线程记录定位。

把 chunkSize 调到 1 就最好吗？ 不是。批次太小会增加调度和状态管理开销，应该以真实设备上的交互响应和任务持续时间为依据。

PerformanceObserver 没有收到条目怎么办？ 先检查 supportedEntryTypes 和观察配置，再确认测试动作确实发生在当前页面；不要把不支持 API 误判成页面性能良好。

Long Tasks 的处理顺序可以固定为：先用 50ms 阈值识别主线程阻塞，再用观察器记录时间和归属，最后把可修改的同步工作拆成批次并在批次间让出主线程。这样优化目标就从“感觉卡”变成了可以对照的任务边界。