INP 从 480ms 降到 120ms：一次 Long Task 拆解与主线程让出实战

结论先行

INP（Interaction to Next Paint）在 2024 年 3 月正式取代 FID 成为 Core Web Vitals 的交互指标后，我们一个 B 端中台的 INP P75 从 480ms 一路恶化到 720ms，连续两周被性能大盘标红。这次治理不是靠「换框架」，而是靠把长任务（Long Task）逐个拆短、把主线程让出去。最终 INP P75 稳定在 118ms，Lighthouse 性能分从 61 提到 94。下面把机制、命令、代码和踩过的坑完整讲清楚。

一、现象与背景：不是「卡一下」，是「整个输入都卡」

我们是一个内部运营后台，单页平均 DOM 节点 6,200+，首屏会并行发起 14 个接口，其中订单聚合接口返回 38 万字节 JSON。用户反馈很具体：表格翻页时鼠标点击「下一页」，界面无响应约 0.5–0.8 秒，期间连滚动条都拖不动。

关键数据（来自 RUM 采集，n=42,300 次交互样本）：

• INP P75 = 720ms（红线 500ms）
• 长任务（>50ms）占交互时长的 41%
• 单次最长 Long Task = 1,860ms，全部集中在「翻页渲染」这一个动作

注意：白屏、报错都很正常，window.onerror 一条都没有。这是 INP 类问题最迷惑的地方——页面没崩，但用户用不了。

二、原理：INP 到底在度量什么，为什么换框架没用

INP 取的是一次页面会话内，除最大那次交互外的第 98 百分位响应时间。响应时间 = 用户输入到下一帧被绘制出来的耗时。它和 LCP、TBT 最大的区别是：它度量的是「用户操作之后」的响应，而不是「打开页面时」。

一个交互为什么会慢，机制上有三层：

1. 主线程被占满：JS 事件循环里，一个同步任务一旦开始，就会独占主线程直到它返回或主动让出。长于 50ms 的任务浏览器会记为 Long Task，直接挤压输入事件的处理。
2. 布局 / 重排（Layout）被触发：翻页时我们重写了整张表格的 200 行 × 12 列 DOM，触发了 14 次强制同步布局（forced reflow）。
3. 合成层不足：大量元素没有 GPU 加速，paint 阶段耗时被放大。

所以「换 React 18 并发渲染」治不了根——并发只解决「组件更新可中断」，不解决「你把 6000 个节点一次性塞给 DOM」这件事。真正的杠杆是把单帧要干的活拆到 50ms 以内。

三、具体做法：四步可复现

1) 先量化：把 Long Task 定位到具体函数

在 devtools 的 Performance 面板录制翻页，或者用 PerformanceObserver 在页面里常驻采样：

const po = new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    if (e.duration > 50) {
      // 拿到 attribution 才能知道是哪个函数/脚本导致的
      console.warn('[longtask]', e.duration.toFixed(0) + 'ms',
        e.attribution?.[0]?.name, e.attribution?.[0]?.scriptId);
    }
  }
});
po.observe({ type: 'longtask', buffered: true });

注意：longtask 事件只在 安全上下文（https） 和 非隐私模式 下可用，本地 http 调试时观察不到，这是第一个坑。

2) 把大渲染拆帧：scheduler.yield + 批量

把「一次渲染 200 行」改成「每次 40 行，让出主线程」：

const { scheduler } = await import('daisyui/scheduler'); // 或用 @scheduler 包
async function renderRows(rows, tbody) {
  const CHUNK = 40;
  for (let i = 0; i < rows.length; i += CHUNK) {
    const slice = rows.slice(i, i + CHUNK);
    const frag = document.createDocumentFragment();
    slice.forEach(r => frag.appendChild(buildRow(r))); // 用 Fragment 减少 reflow
    tbody.appendChild(frag);
    if (i + CHUNK < rows.length) await scheduler.yield(); // 让出主线程
  }
}

仅这一步，单帧耗时从 1,860ms 降到 220ms 区间，Long Task 占比从 41% 掉到 19%。

3) 干掉强制同步布局

代码里有一处 el.offsetWidth 夹在「改样式」和「再改样式」之间，这是经典的 forced reflow。修复：把「读」和「写」分离，先批量写、最后统一读：

// ❌ 每次循环都触发一次 reflow
rows.forEach(r => { r.style.height = '0'; r.offsetHeight; });
// ✅ 写一批，读一次
rows.forEach(r => { r.style.height = '0'; });
const _ = rows[0].offsetHeight; // 一次性读

4) 给高频交互元素上合成层

对会动画/滚动的容器加 transform: translateZ(0)（或 will-change: transform），把 paint 从主线程挪到合成器线程。

四、踩过的坑 & 反直觉之处

1. will-change 不是越多越好：我们一开始给 80 个单元格都加了，结果显存暴涨、低端机上反而更卡。最后只保留在 2 个滚动容器上，INP 才稳住。合成层是有显存成本的。
2. INP 的「第 98 百分位」会让你盯着错的那次交互：最大那次交互不计入 INP，所以你优化了最大的那个卡顿，INP 可能纹丝不动。要盯的是「高频 + 中等耗时」的那批交互。
3. 本地 http 看不到 longtask，导致前两次「优化无效」其实是根本没采到数据。切到 https 后才发现真正的长任务在哪。
4. requestIdleCallback 不能拆渲染：它只在空闲时回调，翻页这种「必须尽快出结果」的场景用它反而把首屏延迟拉长了。拆帧要用 scheduler.yield 这类「可控让出」，而不是「等空闲」。

五、结论与可复用清单

INP 治理的杠杆顺序是：先量化（longtask 归因）→ 拆帧（yield）→ 消除 forced reflow → 上合成层。不要一上来就换框架。

可复用清单：

• [ ] 用 PerformanceObserver({type:'longtask'}) 常驻采样，拿到 attribution 函数名
• [ ] 大列表渲染按 30–50 行/chunk 拆帧，用 scheduler.yield() 让出
• [ ] 读（offsetWidth 等）与写（改 style）严格分离，避免循环内 forced reflow
• [ ] 合成层只给 1–3 个高频滚动/动画容器，不要滥用 will-change
• [ ] 本地调试必须走 https，否则 longtask 事件采不到
• [ ] 盯 INP 的 P75 / 第 98 百分位交互，而不是最大那次

最终成绩：INP P75 720ms → 118ms，Lighthouse 61 → 94，翻页期间滚动条全程可拖。这套方法对任何「重 DOM + 高频交互」的 B 端页面都适用。