浏览器长任务怎么排查：用 PerformanceObserver 定位 50ms+ 主线程卡顿

商品搜索页有个很难复现的问题：接口已经返回数据，用户第一次点击筛选按钮却要等半秒才有反应。Network 面板里看请求耗时只有80ms，真正卡住交互的往往是响应回来之后那段连续运行的JavaScript。接下来用 PerformanceObserver 记录50ms以上的长任务，再拆分验证时间到底是花在JSON解析上，还是后续的同步渲染环节。

先把“页面慢”拆成网络、解析和渲染三个独立模块

我在本地复现的时候给搜索接口返回约2MB的商品JSON，然后在接口回调里连续执行三个操作：JSON.parse、按关键词筛选、把结果一次性插入页面列表。接口请求本身速度不慢，但这段时间主线程被完全占住，浏览器没有机会响应点击、滚动和绘制动作。

先在Performance面板录一段从点击筛选按钮到列表完全渲染出来的完整过程。看Main主线程区域的时候，标记了红色三角的长任务，比单个函数的耗时统计更有参考价值：它直接说明浏览器这段时间被一整条连续任务占住了。不要只盯着Lighthouse的总分，也不要因为接口返回200就直接把性能问题归到服务端头上。

先用 PerformanceObserver 把长任务自动记录下来

监控代码可以放在页面入口或者性能诊断开关里，不建议无条件把每一条记录都上报到线上日志。下面给出的观察器只保留最近20条长任务，方便复现问题的时候直接在控制台查看。

const longTasks = [];

if (PerformanceObserver.supportedEntryTypes.includes('longtask')) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      longTasks.push({
        start: Math.round(entry.startTime),
        duration: Math.round(entry.duration),
        name: entry.name
      });
    }

    if (longTasks.length > 20) {
      longTasks.splice(0, longTasks.length - 20);
    }
  });

  observer.observe({ type: 'longtask', buffered: true });
}

如果控制台里出现 duration: 186，得到的结论也只是“存在一段186ms的连续任务”，还不能直接断定是JSON解析导致的。把这段记录和Performance面板的调用栈对应上，才能确认是 loadProducts、filterProducts 还是列表渲染触发了主线程阻塞。

为什么记录里没有对应的函数名

Long Task条目本身主要提供时间和归因信息，不会自动帮你还原完整的业务调用栈。函数名、脚本文件地址和具体行号要到Performance面板里查看；线上采集数据的时候也应该只保留必要的耗时字段，避免把完整URL、商品内容或者用户输入这类敏感信息带进日志。

对照调用栈验证：整包JSON解析是不是性能瓶颈

在复现页面里给每个处理阶段手动加性能标记，比盲目猜测定位快得多：

performance.mark('products-start');
const products = JSON.parse(responseText);
performance.mark('products-parsed');

const visible = products.filter((item) => item.title.includes(keyword));
performance.mark('products-filtered');

renderProducts(visible);
performance.mark('products-rendered');
performance.measure('parse', 'products-start', 'products-parsed');
performance.measure('filter', 'products-parsed', 'products-filtered');
performance.measure('render', 'products-filtered', 'products-rendered');

我某次演示得到的结果是：解析耗时92ms、筛选耗时38ms、渲染耗时74ms。这里先别急着改CSS优化渲染，三个阶段的耗时加起来已经足够让点击事件进入排队状态。就算把列表改成虚拟滚动之后仍有100ms左右的长任务，就说明数据处理环节本身的问题还没解决。

把大JSON解析拆成可以主动让出主线程的小批次

JSON.parse 没办法安全地切成半个对象来解析，但完全可以避免“解析完立刻全量筛选完再一次性全量渲染完”的串行长流程。实际项目里更稳妥的做法是让服务端直接返回分页数据；如果暂时改不了接口，就把已经解析好的数组的筛选和渲染逻辑拆成小批次执行。

function yieldToBrowser() {
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

async function filterInBatches(items, keyword, batchSize = 200) {
  const result = [];

  for (let start = 0; start 

批次大小不是越小越好。200条一批可能让单批处理耗时稳定低于50ms，但批次太小会增加调度次数，反而让总耗时上升。可以从100、200、500三档分别测试，观察最长任务耗时和筛选按钮响应时间的共同变化，找到最合适的阈值。

重新压测验证，别只靠“感觉变顺了”判断效果

用固定数据量、固定关键词和同一台设备做优化前后的对比，我演示用的测试记录如下，数字只用来展示测量方式：

如果浏览器还是报出长任务，优先检查批次内部是不是又调用了同步模板编译、同步读取图片尺寸或者大量DOM批量插入的逻辑。移动设备、低电量模式和后台标签页的调度策略也会改变运行结果，不能把桌面开发机跑出来的数字当成绝对的固定标准。

常见问题：Long Task 监控的边界说明

PerformanceObserver 能监控接口耗时吗？

它主要用来观察浏览器的性能条目，长任务反映的是主线程的连续执行时间。接口耗时还是要结合Resource Timing、Network面板或者服务端日志来综合判断。

为什么49ms的任务也可能让页面卡顿？

50ms只是Long Tasks的通用识别阈值，不是说耗时低于它页面就绝对流畅。连续多个40ms的任务、频繁布局重排和动画压力也会影响交互表现，需要结合输入延迟和帧渲染表现一起评估。

可以直接把所有JSON解析放进Web Worker里执行吗？

可以考虑这种方案，但要额外承担数据复制、Worker通信和状态管理的成本。先确认主线程确实被JSON解析占满，再评估要不要上Worker；能支持分页返回数据的改造，通常后续维护成本更低。

总结：用实测证据决定拆分位置

排查浏览器卡顿问题的时候，先用Long Task记录确认主线程是不是被连续占用，再用Performance调用栈把网络、解析、筛选和渲染各个环节的耗时拆开。修复阶段优先从分页返回、批次让出主线程、减少同步DOM变更这几个方向入手，最后用长任务数量、最长耗时和用户操作响应时间做复查。这样得到的是逻辑可解释的性能改动，而不是一次“感觉变快了”的盲目调参。