INP 优化思路：拆分长任务、治理第三方脚本保交互流畅

引言：按钮点了没反应

用户反馈”评论框点了半天才弹出来”。这是典型的交互延迟，旧指标 FID 只测首次交互，INP 测的是”所有交互里最差的那次”，更贴近真实卡顿。INP 超标说明主线程经常被长任务占满。

原理分析：长任务是 INP 的元凶

浏览器主线程一次只能干一件事。一段超过 50ms 的 JS 任务就叫”长任务”，期间用户点击无法立即响应，时长直接计入 INP。常见来源：页面初始化时一次性执行的大脚本、第三方分析（GA、GTM、广告）、无防抖的滚动/输入监听。

保姆级实操

1. 用 web-vitals 库采集真实 INP，定位最差交互：

import { onINP } from 'web-vitals';
onINP((metric) => {
  if (metric.value > 200) navigator.sendBeacon('/log/inp', JSON.stringify(metric));
});

2. 拆分长任务：用 setTimeout 或 requestIdleCallback 把大循环切片。

function processChunk(items, i = 0) {
  const end = Math.min(i + 50, items.length);
  for (; i < end; i++) heavy(items[i]);
  if (i < items.length) setTimeout(() => processChunk(items, i), 0);
}

3. 延迟非关键 JS：GTM、聊天插件用 defer 或在 window.load 后再加载。
4. WordPress 侧：用 Asset CleanUp / Perfmatters 按页面禁用不用到的插件脚本；用 wp_dequeue_script 移除多余的。

常见踩坑

1. 只看 Lighthouse 分数，它给的是 TBT 不是真实 INP，必须看 CrUX/字段数据。
2. 把所有脚本都 defer 却没测，关键功能反而变慢。
3. 案例：某站 INP 320ms，查 web-vitals 日志发现最差交互是”滚动加载更多”。原来无限滚动的监听里同步计算了全部文章卡片高度。改成 IntersectionObserver + 切片渲染后，INP 降到 140ms。
4. GTM 容器塞了几十个标签全在首屏触发，主线程爆满。
5. 用 alert/同步 XHR 这类已废弃 API 阻塞线程。

总结

判断标准：INP≤200ms 且全站 ≥75% 达标。行动清单：字段采集定位最差交互 → 拆分长任务 → 延迟/移除第三方脚本 → 按页禁脚本 → 复测。配合CLS 布局偏移修复一起治理体验指标。