从“第一印象”到“全程手感”：指标的进化逻辑
很多前端团队开始关注INP（Interaction to Next Paint），并不是因为追逐Google的新标准，而是因为一个长期存在的痛点：我们用FID（First Input Delay）优化了很久，但页面上那个复杂的表单，或者侧边栏的折叠菜单，依然会在某些时候让人感觉“卡了一下”。FID告诉我们页面第一次交互是否顺畅，但它对后续的用户体验几乎保持沉默。
这种沉默，在强调交互深度的现代Web应用中，逐渐变成了误导。FID就像一个只检查汽车第一次启动的质检员，而INP则要求测试从点火、加速、转向到刹车的整个驾驶过程。自2024年5月起，INP正式在Core Web Vitals中取代FID，这标志着一个根本性的转变——性能评估的重心，从“加载体验”全面转向“交互体验”。
FID的局限：为什么“第一次”不够了
FID的设计初衷是好的，它测量用户第一次点击、触摸或键盘输入时，到浏览器主线程开始处理这个事件的延迟时间。这个指标主要反映主线程的初始繁忙程度。如果页面加载时塞了太多同步脚本，FID值就会很高。
但问题在于，现实中的用户不会只交互一次。一个电商网站的用户可能会进行搜索、筛选、加购、填写地址等一系列操作。FID只捕捉了第一次点击搜索框的延迟，而后面更复杂的、可能触发大量JavaScript计算的“提交订单”按钮的卡顿，却被完全忽略了。我们遇到过不少案例，页面FID得分优秀（小于100毫秒），但用户投诉集中在结算流程缓慢，这正是FID测量盲区导致的优化错觉。
INP的测量机制：更长的链路，更严的审视
INP的“Next Paint”这个词非常精准地定义了它的测量范围。它不再只关心“输入延迟”，而是追踪一次完整交互的整个生命周期：
- 输入延迟：与FID相同，从交互发生到事件处理回调开始执行的时间。
- 处理时间：执行所有相关事件监听器代码的耗时。
- 呈现延迟：浏览器计算样式、布局、绘制，并将下一帧提交到屏幕的时间。
INP值就是一次交互从开始到屏幕给出视觉反馈的总耗时。更重要的是，它统计页面生命周期内所有的交互，并报告一个具有代表性的高分位值（通常是第75或第98百分位）。这意味着，INP暴露的是用户体验中最糟糕的那些时刻。
核心差异对比：不只是范围的扩大
下表清晰地展示了FID与INP在设计哲学和实际影响上的关键区别：
| 特性 | FID (首次输入延迟) | INP (交互至下一次绘制) |
|---|---|---|
| 测量对象 | 仅首次交互 | 所有合格交互 |
| 测量阶段 | 仅输入延迟 | 输入延迟 + 事件处理 + 下一帧绘制 |
| 结果取值 | 实际测量值 | 通常取高分位值（如第75百分位） |
| 反映的问题 | 页面加载期主线程阻塞 | 整个会话期的交互响应能力 |
| 优化盲区 | 忽略异步加载脚本触发的后续卡顿 | 几乎无盲区，能捕获动态内容交互问题 |
这个对比解释了为什么一个“FID良好”的页面可能“INP很差”。例如，一个使用大量第三方组件库的SPA应用，初始加载后主线程很快空闲，FID很好。但当用户展开一个复杂的数据网格时，瞬间执行的JS和触发的重排重绘会导致该次交互的INP值飙升。
INP高的典型场景与排查思路
在实际项目中，高INP值通常不是由单一原因造成的，而是多种因素在特定交互下的叠加。以下是几个常见场景：
场景一：长任务（Long Tasks）未拆分。 这是最常见的元凶。任何在主线程上连续执行超过50毫秒的任务都会阻塞用户交互。一个典型的例子是，在输入框的`onChange`事件中直接进行复杂的列表过滤和DOM更新。
// 可能导致高INP的写法
searchInput.addEventListener('input', (e) => {
const keyword = e.target.value;
// 同步执行过滤、排序、渲染大量列表项
renderList(filterAndSort(hugeDataSet, keyword));
});
// 改进思路：拆分任务，延迟非关键更新
searchInput.addEventListener('input', debounce((e) => {
const keyword = e.target.value;
// 1. 先快速更新UI提示（如“搜索中”）
showLoading();
// 2. 将重型计算放入下一个空闲周期或Web Worker
requestIdleCallback(() => {
const result = filterAndSort(hugeDataSet, keyword);
requestAnimationFrame(() => renderList(result));
});
}, 150));场景二：频繁的布局抖动（Layout Thrashing）。 在事件处理器中交替进行“读”和“写”DOM样式的操作，会迫使浏览器反复执行昂贵的计算样式和布局。这在动画或滚动交互中尤为致命。
场景三：第三方脚本失控。 异步加载的广告、分析或客服脚本，可能在用户交互的关键时刻执行并阻塞主线程。即使它们被标记为`async`，其执行时间也是不可控的。
优化INP的实战建议
优化INP不是一个独立的动作，它要求我们对代码的执行效率和用户体验有更系统的规划。
- 首要任务：监控与定位。 使用Chrome DevTools的Performance面板录制用户交互，重点关注“Main”线程上的长任务条和“Experience”轨道上的INP标记。`web-vitals`库可以方便地在生产环境收集真实的INP数据。
- 代码层面：做减法与拆分。
- 使用`requestIdleCallback`或`setTimeout`将非紧急任务拆分成小块。
- 对于纯计算任务（如数据排序、图像处理），移入Web Worker。
- 为高频事件（如`scroll`、`resize`、`input`）添加节流或防抖，并使用`passive: true`选项避免阻塞滚动。
- 架构层面：管理第三方。 为第三方脚本设置加载超时和执行预算。考虑使用`