你如何诊断运行时卡顿、long task 和糟糕的 INP？

Question

IT Interview Practice · Accepted Answer

运行时卡顿来自**阻塞主线程的 long task**——那是处理 JS、布局、绘制和输入的唯一线程。当一个任务运行太久时，输入无法被处理，于是交互感觉像冻住了，**INP** 也随之攀升。

## 核心模型：主线程

```text
Main thread: [ event handler 180ms ]  input queued... rendered ─▶ INP = time until next paint
             └── a "long task" (>50ms) blocks everything, including responding to the click
```

INP 衡量从一次用户交互到下一次绘制的延迟。它有三个部分：**输入延迟**（点击时主线程正忙）、**处理时间**（你的处理器）和**呈现延迟**（之后的样式/布局/绘制）。

## 诊断

- **Performance 面板**（Chrome DevTools）：录制一次交互，查找被红旗标记的 **Long Tasks**（>50ms）和宽大的处理器帧。
- 用 **PerformanceObserver** 在字段中捕获 long task：

```js
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 50) report("longtask", entry.duration); // find real-user blockers
  }
}).observe({ type: "longtask", buffered: true });
```

## 修复方法

- **拆分 long task**——把工作分块并让出，好让输入能插进来：

```js
async function process(items) {
  for (const item of items) {
    doWork(item);
    if (navigator.scheduling?.isInputPending?.()) await yieldToMain(); // let clicks through
  }
}
const yieldToMain = () => new Promise((r) => setTimeout(r, 0));
```

- **把繁重计算移到 Web Worker**——让解析/运算远离主线程。
- 对昂贵的处理器做 **debounce/throttle**；对长列表做 **虚拟化**；用 memoize 削减重新渲染。
- 用 `requestIdleCallback` 或 `scheduler.postTask` 优先级 **推迟非紧急工作**。

## 为什么这很重要

INP 是最新的 Core Web Vital，也是最难修复的，因为它关乎*运行时*，而不是加载。资深工程师被期望能从单线程模型出发推理——long task 阻塞输入——并主动使用让出、worker 和调度，而不是只说「优化代码」。

核心模型：主线程

诊断

修复方法

为什么这很重要

相关问题