Shopify INP高怎么排查：从慢交互找到主线程瓶颈

Shopify页面加载分数不错，加购却迟迟没有反馈时，应记录具体交互，再看时间花在等待、事件处理还是下一帧呈现。INP关注点击、轻触和按键到下一次画面更新的响应；服务器业务处理是否最终完成，还需要另外核对。

单次交互、单次访问和p75是三个层次

web.dev的INP定义说明：一次页面访问中的INP通常由最慢交互决定；交互很多时，每50次交互忽略一个最高值，得到最差或接近最差的代表值。这一步不是对访问内所有交互取75分位。

现场报告再汇总多次页面访问的INP，采用跨访问的第75百分位数（p75）等口径。Core Web Vitals按移动与桌面分别评估：INP≤200毫秒属于良好，>500毫秒属于较差。不能把一笔250毫秒交互称作“整店p75为250毫秒”。没有可计量交互时可能没有INP，空值不代表0毫秒。

先把慢的一步拆成三段

上图是假设输入等待120毫秒、处理80毫秒、呈现50毫秒，合计250毫秒。只把处理压到40毫秒，其他两段不变时仍是210毫秒；这是独立的算术示例，不能当作改代码就能取得的收益。要改善实际页面，必须定位对应记录。

从用户做什么开始录制

1. 在真实用户报告里按设备、页面类型或URL找问题范围，保存日期、样本与部署记录；报告用法见后台与PageSpeed的口径区别。
2. 在相应页面复现选规格、筛选、输入搜索、打开购物车或加购。既测加载完成后的操作，也测页面仍在加载时的操作。
3. 用Performance录制包含该动作的trace，找到交互记录及三段时间，再关联调用栈、长任务与布局工作。
4. 对照Network的发起链和脚本来源，核是主题、应用、像素还是其他集成。某域名同时发请求只说明时间相关，不能单独证明它造成主线程阻塞。
5. 固定设备或节流、网络、缓存、市场、同意状态和动作，保存多次原始记录，再比较修订。

INP优化指南建议结合现场与实验室定位；Shopify的INP说明也解释了交互响应问题。滚动和悬停不是INP计量的交互类型，但它们触发的重工作可能占用主线程，影响随后点击。动画流畅度与完整业务完成时间应另外记录。

按证据选择改法，不按脚本名字开删

若时间耗在自己的回调，先看是否重复绑定、反复同步读写布局、一次处理过多内容；根据依赖拆分长工作，尽早让必要反馈呈现。拆分不能让价格、库存或加购对象短暂不一致。控制高频搜索或滚动处理时，也要核用户最后一次输入是否仍会生效。

若需要调整第三方加载，先依据脚本归属清单确认业务用途和可配置方式。按模板或实际需要加载可能有帮助，但把所有脚本推到首次点击后，会把下载与初始化集中到那次交互。统计、同意管理、客服和购买流程须随改动回归，不能为跑分直接移除。

应用输出不必然全在同一执行环境，像素可能运行在相应沙箱；归属、执行开销和能否由主题修改要实查。是否能换成已有功能，可用平台、主题与官方应用的替代比较，退出清理另按卸载检查处理。

为什么实验室、后台和自采数据会不同

只观察导航加载的Lighthouse运行并没有覆盖完整访问中的用户操作。TBT可辅助发现阻塞，却不是INP；不能拿TBT下降直接宣布INP达标。Performance也不限于单次加载，它可以录制加载后的实际交互。

页面级INP包含iframe中的交互，但页面JavaScript无法直接获得跨域iframe内的相关计时；自采与CrUX等来源可能因此不同。需要自建监测时，应使用适用的web-vitals库并按实际版本接入现有分析系统，核上报时机、样本和数据最小化；在控制台打印一次值还不是完成监测。

修复结论应同时说明：哪个动作在什么条件下改善，哪些功能已回归，以及现场同口径数据后来怎样变化。一次局部复现通过，不代表全部访客、所有页面或搜索排名都改善；整套基线可接着看Shopify性能指标与基线。