INP成为核心指标之后，外贸站的交互延迟优化实测

有个现象值得注意：不少外贸站在核心网页指标上一直是绿的，某天突然变成黄的或红的，站点本身却什么都没改。

原因通常是同一个——衡量交互响应的指标从 FID 换成了 INP。FID 只看第一次交互，宽容得多；INP 把整个访问过程里的交互都算进来，取接近最差的一次。

这篇讲清楚两者差在哪、外贸站为什么特别容易在这上面翻车、以及具体怎么排查和改。文里的阈值和计算规则都注明了出处，可以自己核对。

一、INP 和 FID 的本质差别

先把定义对齐。INP（Interaction to Next Paint，交互到下一次绘制）是 FID（First Input Delay，首次输入延迟）的继任指标。

FID 只测一件事，而且只测一次

FID 测的是：用户第一次与页面交互时，浏览器开始执行对应事件处理器之前等了多久。注意两个限定——第一次，以及只算开始执行之前的等待。

这意味着两种情况都会被 FID 放过：一是用户第一次点击发生得比较晚、那时页面已经空闲了；二是事件处理器本身跑了三秒，但开始执行得很快。后者的用户体验很糟糕，FID 却是优秀。

INP 测的是完整的一次交互，而且测所有交互

INP 把一次交互拆成三个阶段：

1. 输入延迟（Input delay）：从用户操作发生，到事件处理器开始运行之前的这段等待

2. 处理时长（Processing duration）：所有事件处理器回调执行完所花的时间

3. 呈现延迟（Presentation delay）：从回调执行完，到浏览器把下一帧画到屏幕上的时间

三段加起来，才是用户真正感受到的「我点了之后多久有反应」。

阈值与计算规则

几条容易忽略的计算规则：

• 只有三类操作算交互：鼠标点击、触摸屏点按、物理键盘或屏幕键盘上的按键。滚动和鼠标悬停不算

• 取的不是平均值。对交互次数多的页面，每 50 次交互会忽略其中最高的一次，以排除极端值

• 最终报告的是所有页面浏览的第 75 百分位数，这一步进一步去掉了离群值

来源：web.dev《Interaction to Next Paint (INP)》，链接见文末。

外贸站为什么特别容易在这里翻车

因为外贸站的交互恰好都集中在页面加载之后的那一段，而且大多是重交互：

• 产品筛选器：选一个规格，页面要重新过滤几百上千条数据并重绘列表

• 多级导航菜单：鼠标点开一个大菜单，要渲染几十个链接

• 语言切换：一次点击可能触发整页重载或大规模文本替换

• 在线聊天挂件：点开的一瞬间要加载和初始化一整套第三方脚本

• 询盘表单：字段较多，实时校验如果写得重，每次输入都在占主线程

• 产品图轮播与放大镜：图片切换和缩放计算量都不小

这些操作在 FID 的口径下几乎都不会被测到，在 INP 的口径下每一次都算数。

二、三个站的初始诊断数据

五、实验室数据与字段数据的落差

这一节解释一个让很多人困惑的现象：本地测出来一切正常，线上报告还是不合格。

实验室工具测不出 INP

INP 需要真实用户的真实交互才能产生。实验室工具在没有人操作的情况下跑一遍页面，拿不到 INP 值。

实验室里能用的替代参照是总阻塞时间（TBT）——它衡量主线程被长任务阻塞的程度，和 INP 的第一个阶段（输入延迟）高度相关。TBT 降下来，INP 通常会跟着改善，但两者不是一回事：TBT 好看而 INP 差的情况完全可能存在，因为 TBT 管不到处理时长和呈现延迟。

字段数据的更新机制

字段数据来自 Chrome 用户体验报告（CrUX）。几个关键机制：

• 数据是28 天滚动平均

• 每天更新一次，大约在世界协调时 04:00 前后，没有服务等级承诺，按尽力而为的方式运行

• 数据比当前日期滞后约两天

• 页面或来源要出现在 CrUX 里，需要满足两个条件：可被搜索引擎索引（不能被 noindex、X-Robots-Tag 屏蔽，且返回 200 状态码），以及有足够的访问量（具体阈值未公开）

来源：Chrome 开发者文档 CrUX API 与方法论页面，链接见文末。

这直接解释了为什么改完之后看不到变化：28 天的滚动窗口意味着，改动落地后的第一周，窗口里还有三周的旧数据在拉低平均。要看到完整效果，至少要等一个完整的 28 天周期。

流量不够怎么办

如果页面访问量达不到 CrUX 的门槛，就没有字段数据可看。三个替代方案：

1. 看来源级数据。即便单个页面没有数据，整站来源级的数据可能是有的。注意来源级数据会把所有页面混在一起，定位不到具体页面

2. 自己采集真实用户数据。在站上部署官方的 web-vitals 库，把每次交互的 INP 值连同页面路径、设备类型一起上报到自己的分析工具。这是唯一能在低流量站上拿到精确数据的方法，也能看到具体是哪个元素引起了最差的那次交互

3. 在本地做手工交互测试。用开发者工具的性能面板录制一段真实操作（点菜单、点筛选、填表单），逐个交互看耗时分解。这个方法拿不到统计意义上的数值，但足以定位问题元素

对大多数外贸站，第二个方案是最值得做的。 部署成本不高，而且它能回答字段数据回答不了的问题：到底是哪个按钮、哪个交互拖垮了整体数值。

六、一份 INP 排查顺序清单

按这个顺序走，不要跳步。前面几步成本低、收益高。

1. 确认问题范围。在 PageSpeed Insights 里分别看移动端和桌面端、页面级和来源级的 INP，记录基线和采集日期

2. 分清是哪一类页面的问题。首页、列表页、详情页、文章页各测一个，问题通常集中在列表页和详情页

3. 用开发者工具录一段真实交互。点开菜单、用一次筛选、点一次聊天按钮、填一次表单，看每个交互的耗时分解，确认问题出在输入延迟、处理时长还是呈现延迟

4. 盘点第三方脚本。列出页面上加载的所有第三方脚本及其体积，逐个问一句：这个脚本必须在页面加载时就跑吗

5. 把可以延后的第三方脚本改成交互触发加载。聊天、热图、A／B 测试、视频播放器优先处理

6. 检查关键交互元素上的监听器数量，清理插件和主题的重复绑定

7. 优化最重的那个事件处理器。用先反馈后计算的模式改写，把非关键工作移出同步流程

8. 检查 DOM 规模。节点数过大的页面做分页或虚拟滚动

9. 拆分剩余的长任务，每块控制在几十毫秒以内

10. 部署真实用户监测，持续记录改动后的实际变化

11. 等一个完整的 28 天周期再下结论，中途的数据都是新旧混合的

最后两句提醒

一次只改一项。 同时改五个地方，字段数据变好了也不知道是哪个起的作用，下次遇到同样问题还得重来一遍。

INP 是体验指标，不只是排名指标。 点了没反应会让用户直接离开，这个损失在询盘数据上的体现，通常比在排名上的体现更早也更明显。把它当成转化优化的一部分来做，动力会足一些。

常见问题

Q1. INP 不达标会影响排名吗？

核心网页指标是谷歌排名信号的一部分，但它的权重远低于内容相关性和质量。实际情况是：INP 不达标不会让一个内容优秀的页面掉出首页，但在内容质量接近的竞争中，它可能成为区分因素。更值得关注的是另一层影响——点击后没有反应会直接造成用户离开，这个损失体现在询盘数据上通常比体现在排名上更早也更明显。建议把 INP 当成转化优化来做，排名上的收益当作附带。另外要注意，核心网页指标的评估是按页面级和来源级分别进行的，如果大量页面不达标，来源级数据也会受影响。

Q2. 哪些插件最容易拖垮 INP？

从实际排查经验看，最常见的四类是：在线聊天挂件（体积大且通常在页面加载时就全量初始化）、热图与会话录制工具（持续监听用户行为，本身就在占用主线程）、弹窗营销类插件（倒计时、退出挽留、优惠提示）、以及功能重叠的多套统计和转化像素代码。判断方法很简单：在开发者工具里按体积和执行时间列出所有第三方脚本，逐个问「这个脚本必须在页面加载时就跑吗」。多数情况下，聊天、热图、A／B 测试、视频播放器都可以改成用户表现出意图时再加载。另外别忘了检查重复监听器——主题自带一个、插件加一个、自定义代码再加一个，每次点击全部执行一遍，这个问题在装了很多插件的站上几乎必然存在。

Q3. 移动端和桌面端要分别优化吗？

要，而且两者的差距通常很大。原因有三个：移动设备的 CPU 性能普遍弱于桌面，同样的 JavaScript 执行时间可能差好几倍；移动网络条件更不稳定，第三方脚本的加载时机更难控制；移动端的交互方式是触摸，用户对延迟的感知阈值更低。实际做法上，建议以移动端为优化基准——移动端达标了，桌面端基本不会有问题，反过来不成立。测数据的时候也要分开看，PageSpeed Insights 默认展示的就是分设备的数据，不要只看一个。对外贸站还有一个额外理由：很多目标市场（尤其是拉美、东南亚、中东）的移动端流量占比明显高于欧美，移动端体验直接决定询盘量。

Q4. 改完多久字段数据才更新？

要等一个完整周期，通常是四周左右。具体机制是：字段数据来自 Chrome 用户体验报告，采用 28 天滚动平均，每天更新一次（大约在世界协调时 04:00 前后，按尽力而为方式运行），并且比当前日期滞后约两天。这意味着改动落地后的第一周，28 天窗口里还有三周的旧数据在拉低平均值，看到的改善幅度会远小于实际效果。正确的做法是记录改动落地的准确日期，改完先看实验室指标（总阻塞时间）确认方向对不对，然后等满 28 天再看字段数据下结论。这也是为什么建议一次只改一项——如果每周改一样，几个月后你会完全分不清是哪一项起了作用。

Q5. 没有足够流量看不到字段数据怎么办？

有三个替代方案。第一，看来源级数据——即便单个页面达不到门槛，整站来源级的数据可能是有的，但它把所有页面混在一起，定位不到具体页面。第二，也是最推荐的，在站上部署官方的 web-vitals 库自己采集真实用户数据，把每次交互的 INP 值连同页面路径、设备类型、触发元素一起上报到自己的分析工具。这是低流量站唯一能拿到精确数据的办法，而且它能回答字段数据回答不了的问题：到底是哪个按钮拖垮了整体数值。第三，用开发者工具的性能面板录制一段真实操作（点菜单、用筛选、点聊天按钮、填表单），逐个交互看耗时分解——拿不到统计意义上的数值，但足以定位问题元素。对大多数外贸站来说，第二个方案部署成本不高，值得做。