页面加载很快，但感觉还是很慢？

你的页面加载很快，但感觉还是很慢？

你的 Lighthouse 报告是绿色的。你的 LCP 和 CLS 分数看起来不错。你的页面加载很快。但随后你的真实世界得分却下降了。你不知道为什么。

问题通常出在 INP。

INP 代表 Interaction to Next Paint（交互到下次绘制）。它在 2024 年 3 月取代 FID 成为 Core Web Vital。FID 仅测量第一次点击的延迟。而 INP 测量用户使用页面时的每一次交互，并报告其中最慢的一次。

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

Google 使用以下规则：

• 200ms 或更少为“良好”。
• 超过 500ms 为“差”。

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

Lighthouse 不会去点击你的按钮。它只是给你一个估算值。你可能会同时拥有绿色的实验室报告（lab report）和红色的实测得分（field score）。

要查看真实数据，请在交互发生时进行测量。使用以下代码：

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

这会记录下慢速交互及其背后的元素。现在你可以修复真实的问题，而不是靠猜。

当主线程忙碌时，就会出现 INP 问题。在 JavaScript 任务完成之前，浏览器无法绘制响应。长任务（long task）会阻塞交互。

常见原因：

• 沉重的事件处理器在每次点击时执行过多工作。
• 第三方脚本（如聊天组件或分析工具）运行长任务。
• 在循环中读取和写入 DOM 导致的布局抖动 (layout thrash)。
• 框架的注水 (hydration) 过程。

你可以通过拆分长任务来解决这个问题。让浏览器“喘口气”。

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

目标是在慢速工作开始之前完成响应的绘制。

其他建议步骤：

• 延迟加载页面不需要立即使用的脚本。
• 审计第三方组件。
• 对高开销的处理器进行防抖 (debounce) 处理。
• 批量处理 DOM 的读取和写入。

如果你的实验室报告是绿色的，但实测得分是红色的，就不要再盯着 LCP 不放了。去测量你的交互吧。

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