内联脚本影响交互响应，机制只有一条：它占了主线程的时间，而用户点击之后要等主线程空出来才能看到界面变化。INP 量的是从用户交互发生到下一次绘制之间的这段间隔，建议值是不超过 200 毫秒，按第 75 分位、并在移动端和桌面端分别衡量。这里有一处必须写对的常见误解：INP 属于真实用户数据，实验室环境里没有真人点击就测不出来，实验室只能用总阻塞时间（TBT）作为代理指标，而 TBT 是代理、不是替代品。
INP 记的是哪一段时间
web.dev 关于 INP 的说明把它定位为衡量响应能力的核心网页指标，依据是 Event Timing API 采集的数据。分档写法也很明确：不超过 200 毫秒属于响应良好，高于 200 毫秒且不超过 500 毫秒属于需要改进。衡量口径是所有页面访问的第 75 分位，并按设备类型分开，这一层分位数的作用是剔除离群值，让结果更接近绝大多数用户的实际感受。
这份文档还划掉了几个常见误解：滚动、悬停、缩放都不算 INP；INP 关注交互延迟而不是页面完全可交互的时间，衡量的是延迟而不是交互本身的耗时。这些排除项直接决定优化方向——如果你的慢来自"点了之后要等接口返回再更新界面"，那和"点了之后主线程被脚本占住"是两件事，前者要考虑预取和更快的响应，后者才是本文要处理的。
为什么实验室测不出 INP
web.dev 的核心网页指标总览里写得很直接：像 Lighthouse 这类在模拟环境中加载页面、没有真实用户输入的工具，无法测量 INP。文档给出的替代路径是总阻塞时间——TBT 在实验室可测，是 INP 的代理指标；实验室里改善 TBT 的优化，可能会改善真实环境里的 INP，但文档同时说明实验室测量不能替代真实测量。
这条区别意味着两件事。第一，你在 Lighthouse 里看到的交互相关分数是 TBT 不是 INP，别当成 INP 的读数。第二，INP 的分档判断只能靠真实数据：Search Console 的核心网页指标报告、自建的真实用户监测，或文档提到的 Chrome 用户体验报告。这也是为什么"用工具测一下就知道"在交互响应上不成立。
怎么做：把内联脚本拆小
- 先在开发者工具里跑一遍性能记录，找出长任务。文档写明长任务的问题在于会阻塞主线程响应交互。
- 找出真正该执行的那部分，删掉其余的。文档的说法是：网站发送的 JavaScript 越来越多，JavaScript 过多时任务会争抢主线程；可用的做法包括使用已经广泛支持的基础 Web 平台特性替代冗余的 JavaScript 实现，以及清理标签管理器里带无用代码的旧标签。
- 把剩下的大块工作切成小段，主动让出主线程。文档建议通过频繁让出主线程来打断长任务，让渲染更新和其他交互能更早发生。
- 把强制布局和布局抖动这一类重排工作重新组织，避免脚本里 DOM 读取与写入顺序不当导致反复回流。
- 第三方脚本放到关键的第一方内容之后，并加上异步或延迟加载属性。web.dev 那份第三方嵌入最佳实践里给的就是这个顺序，理由是第三方请求会挡在第一方内容前面。
| 症状 | 更可能的原因 | 先动哪里 |
|---|---|---|
| 页面刚打开时点任何东西都卡 | 长任务占住主线程 | 拆任务、让出主线程、减少不必要脚本 |
| 点了要等一秒多才有反应 | 接口往返加渲染延迟 | 预取数据、先更新界面再等结果 |
| 用工具测不出问题，真实用户却说卡 | 实验室缺真实输入 | 去看真实数据的第 75 分位 |
| 只有关键词输入类交互慢 | 输入处理路径单次计算量太大 | 该路径单独做性能记录 |
第 2 步和第 5 步的判断依据来自web.dev 关于最有效的核心网页指标优化方法和web.dev 关于第三方嵌入最佳实践。第三方脚本为什么单列一行值得盯，站内那篇用 WordPress 建站丨哪些插件会拖慢速度影响排名讲的是识别环节：先把来源查清楚，再谈处理。
这套做法什么时候收益很小
几种情况下这套做法不划算。页面交互本来就很轻——只有文字和链接的静态页脚本量本来就小，拆任务没意义。瓶颈在接口而不是主线程时更明显：服务端响应 800 毫秒、前端脚本总共执行 30 毫秒，拆脚本的收益接近零，先去看服务端。已经维护一份很重的单页应用、短期做不了大改时，能做的是把首屏关键交互的路径单独拎出来优先处理。
还有两条必须写明的边界。第一，FID 已被 INP 取代，指标口径以 INP 为准，看旧资料时注意区分年代。第二，官方从未公布过"多少毫秒的脚本执行就会导致被降权"这类换算，web.dev 给的 200 毫秒是响应良好与否的建议分档，不是排名门槛；把脚本执行时间直接换算成排名影响，是文档里读不出来的结论。
两路验证各查什么
验证分实验室和真实两路。实验室这路用性能记录定位长任务、用 TBT 作代理看趋势——注意它只是代理。真实这路拿第 75 分位的 INP 数据，Search Console 的报告可以先看整体，再自建监测定位到具体是哪种交互、发生在加载期间还是之后。
改动的排期方式建议这样定：一次只改一类脚本，改完当天在实验室重测一次 TBT，一周后回看真实 INP 的第 75 分位，中途不要动缓存策略。WordPress 站上缓存和动态页面的边界容易和脚本调整互相干扰，WordPress 加速先选插件还是调服务器：缓存、CDN 与动态页面怎么分工里给过分工口径；各项工具的用途怎么定位，WordPress SEO 与性能优化：10 款工具的用途与选型注意事项按指标类型分过类。