前端长任务治理实战：用 PerformanceObserver 找出页面卡顿源头

前端页面卡顿有时并不是接口慢，也不是 CSS 写得太复杂，而是 JavaScript 在主线程上连续执行太久。用户点击按钮以后，浏览器需要处理输入、执行脚本、计算样式、布局、绘制，如果某一段脚本占住主线程超过 50ms，就可能形成 Long Task，直接拖高 INP，页面看起来就像“点了没反应”。

这篇文章用一个常见的列表筛选场景，演示如何用 PerformanceObserver 捕获 Long Task，再把大计算拆成小片段，必要时迁移到 Worker，让交互重新顺滑起来。

适合人群：做过前端业务开发，想排查页面卡顿、点击延迟、输入不跟手问题的同学。你需要了解一点 JavaScript 事件循环和浏览器 DevTools 基础。

目录

• 一、先判断是不是主线程被长任务占住
• 二、用 PerformanceObserver 把 Long Task 记录下来
• 三、把一次性重计算拆成可让出的分片任务
• 四、什么时候应该上 Worker
• 五、常见坑和上线检查清单

一、先判断是不是主线程被长任务占住

假设页面里有一个订单列表，用户输入关键词后会在前端做筛选、排序、分组和统计。数据只有几千条时还好，一旦达到几万条，点击筛选按钮后页面就会短暂停住：按钮 hover 状态不刷新，loading 转不起来，输入框光标也会卡一下。

这种现象的关键不是“代码总耗时多少”，而是“单次连续占用主线程多久”。如果一段同步脚本跑了 180ms，这 180ms 内浏览器不能及时响应用户输入，也不能插入绘制。

排查时可以先打开 Chrome DevTools 的 Performance 面板录制一次操作。如果 Main 线程上出现连续的大块脚本任务，并且点击、输入、滚动附近都有明显等待，就可以继续把监控代码接入页面，拿到线上真实数据。

二、用 PerformanceObserver 把 Long Task 记录下来

浏览器提供了 Long Tasks API，可以观察页面里的长任务。基本思路很简单：注册一个 PerformanceObserver，监听 longtask entry，再把任务耗时、开始时间和当前页面上下文打点上报。

function observeLongTasks(report) {
  if (!("PerformanceObserver" in window)) return;

  try {
    const observer = new PerformanceObserver((list) => {
      for (const entry of list.getEntries()) {
        report({
          type: "longtask",
          startTime: Math.round(entry.startTime),
          duration: Math.round(entry.duration),
          page: location.pathname,
          visibility: document.visibilityState,
          url: location.href
        });
      }
    });

    observer.observe({ entryTypes: ["longtask"] });
  } catch (error) {
    console.warn("longtask observer failed", error);
  }
}

observeLongTasks((payload) => {
  navigator.sendBeacon("/perf/longtask", JSON.stringify(payload));
});

这段代码建议放在业务入口尽早执行。上报时不要塞太多字段，Long Task 本身可能已经发生在繁忙阶段，上报逻辑越轻越好。线上看数据时，优先按页面路径、设备档位、任务时长区间聚合，先找“最常见的卡顿入口”，而不是盯着单个极端样本。

如何和用户操作关联

Long Task 只告诉你主线程卡住了，不一定告诉你是哪次点击触发的。实际项目里可以在关键交互入口记录一个轻量上下文，例如按钮名称、列表规模、筛选条件数量，再把最近一次交互上下文带到上报里。

let lastAction = null;

function markAction(name, extra = {}) {
  lastAction = {
    name,
    extra,
    time: performance.now()
  };
}

document.querySelector("#filterBtn").addEventListener("click", () => {
  markAction("filter_orders", {
    rows: window.__ORDER_COUNT__ || 0
  });
  runFilter();
});

上报 Long Task 时，如果 performance.now() - lastAction.time 在 2 秒内，就把 lastAction 一起带上。这样你很快能看到“订单筛选”“图表重算”“富文本初始化”到底哪个更容易制造卡顿。

三、把一次性重计算拆成可让出的分片任务

发现问题以后，不要急着把所有逻辑都搬走。很多卡顿来自一次性同步循环，比如遍历 5 万条数据做过滤和统计。第一步可以把大任务拆成小块，每处理一段就把控制权还给浏览器。

下面是一个简化版分片执行器。它每次只处理一部分数据，达到时间预算后主动让出，下一帧或空闲时间继续处理。

function nextFrame() {
  return new Promise((resolve) => requestAnimationFrame(resolve));
}

async function filterInChunks(items, predicate, onProgress) {
  const result = [];
  const budget = 8;
  let index = 0;

  while (index < items.length) {
    const start = performance.now();

    while (index < items.length && performance.now() - start < budget) {
      const item = items[index++];
      if (predicate(item)) result.push(item);
    }

    onProgress?.({
      done: index,
      total: items.length,
      result
    });

    await nextFrame();
  }

  return result;
}

这里的 budget 不要设得太满。16.7ms 是 60fps 下每帧总预算，脚本不应该独占全部时间。实际项目可以从 6ms 到 10ms 之间试起，再根据设备档位和页面复杂度微调。

在 React/Vue 里怎么接

框架里也一样，核心是不要在一次点击回调里完成所有重活。可以先把按钮状态和 loading 状态提交出去，再异步分片计算，过程中更新进度或展示骨架屏。

async function handleFilterClick() {
  setLoading(true);
  await nextFrame();

  const filtered = await filterInChunks(
    orders,
    (order) => order.status === selectedStatus,
    ({ done, total }) => setProgress(Math.round((done / total) * 100))
  );

  setRows(filtered);
  setLoading(false);
}

这类优化的收益很直观：总计算时间可能没有明显降低，但用户可以看到按钮状态变化、进度条更新，输入和滚动也不会被一次大循环完全堵住。

四、什么时候应该上 Worker

如果任务只是几十毫秒，分片通常够用。如果任务本身很重，比如复杂报表计算、全文搜索索引、图片处理、加解密、压缩解压，就应该考虑 Worker。Worker 的价值是把 CPU 密集型工作从主线程挪开，让 UI 线程继续响应用户。

// main.js
const worker = new Worker("/workers/order-filter.js", { type: "module" });

worker.postMessage({
  type: "filter",
  payload: {
    orders,
    status: selectedStatus
  }
});

worker.onmessage = (event) => {
  if (event.data.type === "filtered") {
    setRows(event.data.payload.rows);
    setLoading(false);
  }
};

// workers/order-filter.js
self.onmessage = (event) => {
  const { type, payload } = event.data;
  if (type !== "filter") return;

  const rows = payload.orders.filter((order) => {
    return order.status === payload.status;
  });

  self.postMessage({
    type: "filtered",
    payload: { rows }
  });
};

Worker 不是免费午餐。数据需要序列化和传输，结果也要再传回来。如果每次只处理几百条数据，Worker 的通信成本可能比收益还大。判断标准很朴素：任务持续制造 Long Task，且任务逻辑和 DOM 操作没有强绑定，就可以拆到 Worker。

五、常见坑和上线检查清单

1. 只看平均值，忽略低端设备

前端性能问题经常在低端 Android 或后台标签页里放大。上报时至少记录设备内存、网络类型、页面可见性和数据规模，分析时看 P75、P90，而不是只看平均值。

2. 分片后频繁 setState

分片计算时如果每处理几十条就更新一次状态，反而会制造更多渲染压力。进度更新可以节流，例如 100ms 更新一次，或者只在百分比变化明显时更新。

3. Worker 里访问 DOM

Worker 不能直接操作 DOM。把数据计算和 UI 更新边界切清楚：Worker 负责算，主线程负责渲染。

4. 上报代码本身太重

性能监控代码应该轻量。不要在 Long Task 回调里同步读取大量 DOM、拼接巨大对象、阻塞式写日志。推荐使用小 payload，加上采样和批量上报。

总结

治理前端卡顿可以按三步走：先用 DevTools 和 PerformanceObserver 证明主线程是否被 Long Task 占住，再把线上 Long Task 和关键交互关联起来，最后根据任务重量选择分片、让出或 Worker。性能优化不只是让代码跑得更快，更重要的是让浏览器有机会及时响应用户。

如果你的页面已经出现点击延迟、输入卡顿、loading 不转的问题，可以先把 Long Task 观察器接上去。数据跑一天以后，通常就能看到最值得动刀的那几个入口。