页面加载很快但感觉很慢？那是 INP 的问题

页面加载很快，但感觉很慢？那是 INP 的问题

你的 Lighthouse 报告显示为绿色。 LCP 表现良好。 CLS 表现良好。 页面加载速度很快。

但你的真实用户数据（real-world scores）却下降了。 你不知道原因。

问题很可能出在 INP 上。 Interaction to Next Paint 在 2024 年 3 月取代了 FID。 FID 仅测量第一次延迟。 INP 则测量用户停留在页面上的每一次交互。 它报告的是最慢的那一次。

INP 不是一个加载指标。 它是一个响应性指标。 它回答了一个问题：当你点击或输入时，屏幕需要多久才会发生变化？

Google 使用以下分级：

• 200ms 或更少为“良好 (good)”。
• 超过 500ms 为“较差 (poor)”。

一个网站可能在一秒内加载完成，但仍然无法达标。 “加载快”和“响应快”是两回事。

Lighthouse 工具经常会忽略 INP。 Lighthouse 不会去点击你的按钮。 它提供的是一个估算值。 你可能会遇到实验室报告（lab report）是绿色的，但真实用户数据（field score）却是红色的情况。

要查看真实数值，请使用以下代码：

import { onINP } from 'web-vitals';
onINP(function (metric) {
  console.log('INP', metric.value, metric.entries);
});

这会记录下慢速交互及其对应的具体元素。

INP 问题发生的原因是主线程（main thread）太忙了。 在 JavaScript 任务完成之前，浏览器无法绘制响应。

常见原因：

• 每次点击时都会运行沉重的事件处理器（event handlers）。
• 第三方脚本，如聊天组件或分析工具。
• 因频繁的 DOM 读写导致的布局抖动（Layout thrashing）。
• 框架的注水（hydration）任务。

通过拆分长任务来修复它。 在步骤之间让浏览器“喘口气”：

async function onClick() {
  doUrgentPart(); 
  await yieldToMain(); 
  doExpensivePart(); 
}

使用 yieldToMain 让浏览器在开始耗时工作之前先绘制 UI。

其他修复方法：

• 延迟加载不需要立即使用的脚本。
• 审计第三方组件。
• 对耗时的处理器进行防抖（Debounce）处理。
• 批量处理 DOM 的读写操作。

如果你的真实得分很低，就不要再盯着 LCP 不放了。 去测量你的交互性能吧。

Source: https://dev.to/lamas51/your-page-loads-fast-but-still-feels-slow-its-inp-not-load-time-2gkn