1. 主页
  2. 专题文章
  3. 在 Seven Branches 中追溯失败的 INP 代码行

在 Seven Branches 中追溯失败的 INP 代码行

2026 年 9 月 21 日 · 阅读时间：9分钟
在 Seven Branches 中追溯失败的 INP 代码行

只有找出三个阶段中哪个阶段耗时过长，才能确定红色 INP 分数是否真的存在性能问题。大多数团队会忽略这一步，直接购买缓存插件或延迟执行脚本，然后眼睁睁地看着 75% 的分数停滞不前。而我们采用的决策树则截然不同：它包含七个分支，引导你从 Chrome UX 报告中的低分值逐步找到具体导致问题的处理程序、脚本或第三方代码，每个分支都设有明确的阈值。本指南专为负责转化率和 Lighthouse 分数的前端负责人和增长团队而编写。

差距是真实存在的。在《2025年网络年鉴》中， 77%的移动端来源具有良好的INP 相比桌面端的 97%，而且只有 48% 的移动端网站通过了所有三项核心网络指标的测试 (HTTP档案移动端目前仍然存在的问题主要是交互延迟，而且这些问题大多是可以诊断出来的。

INP衡量什么，以及它悄悄忽略什么

交互到下一绘制报告每次页面访问的交互延迟为： 75％ 跨越你的起源。美好是 200 毫秒或更短需要改进的延迟时间在 200 毫秒到 500 毫秒之间，较差的延迟时间超过 500 毫秒（网络开发关于这个定义，有三点会改变你调试它的方式：

  • 只有点击、轻触和按键操作才算数。悬停、缩放和 滚动次数不予测量因此，滚动不流畅会让页面感觉像是坏掉了，而 INP 却保持绿色。
  • 在交互较多的页面上，INP 忽略每 50 次互动中最高的一次。因此，罕见的灾难性交互可能隐藏在高参与度页面上，而在低参与度页面上浮现。
  • 每一次互动都会分裂成 输入延迟 （在你的处理程序运行之前）， 处理时长 （您的处理程序正在运行） 演示延迟 （在你的句柄之后，帧绘制之前）。这三个问题在工程学上几乎没有任何共同之处（网络开发).

最后一点才是整个方法。你调试的不是“INP”，而是三个阶段中的一个，每个阶段都有不同的修复方法。

分支 0：触摸密码前请确认号码真实有效

打开 PageSpeed Insights，查看字段部分，而不是实验室评分。实验室工具无法衡量 INP（点击事件处理），因为 INP 需要真实用户进行点击操作。如果源站没有字段数据，则说明存在流量问题，而非性能问题，以下任何内容均不适用。然后分别提取移动端和桌面端的数据——预计到 2025 年，全球移动端和桌面端的差距将达到 20 个百分点。如果移动端显示为红色而桌面端显示为绿色，请停止在笔记本电脑上进行测试。

分支 1：缓慢的交互发生在加载过程中还是加载之后？

用仪器监测现场 web-vitals 归因构建。只需四行代码即可获取数据：

import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
  navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});

了解 attribution.loadState 首先。如果大多数糟糕的交互都带有负载状态 装载 or dom-interactive用户在您的脚本仍在执行时就进行了点击操作：这是交付问题，需要在打包和标签管理器中修复，而不是在处理程序中修复。如果不良交互分散在已加载的页面上，请切换到分支 2。

分支 2：时间归哪个子部门所有？

历史记录 inputDelay, processingDuration 和 presentationDelay 对于每个样本。我们的工作规则：当一个子部分考虑到了以下情况时，它就拥有交互作用： 超过50%的INP总额如果没有任何一个线程的拥塞率达到 50%，则首先将其视为输入延迟问题——主线程拥塞扩散通常是导致其他两个线程拥塞率上升的原因。

主导子部分先进行调查典型原因首次修复
输入延迟 > 50%longAnimationFrameEntries 调用者类型加载期间的脚本评估；计时器；之前的交互仍在运行延迟或移除第三方脚本；拆分软件包；将周期性工作移出线程
处理时间 > 50%longestScript 和 totalScriptDuration一个开销较大的事件处理程序；一个触发完整重新渲染的状态更新在处理程序内部让步；将非视觉工作移至下次绘制之后。
演示延迟 > 50%totalStyleAndLayoutDuration大型 DOM；布局频繁切换；重量级 requestAnimationFrame 工作减小 DOM 大小；应用 content-visibility批量读写
没有子部分 > 50%以上所有主线程拥塞将其视为输入延迟，重新测量，然后重新分支。

分支 3：命名脚本

属性构建中包含每个 INP 样本的长动画帧条目。 attribution.longestScript 提供交互中最糟糕脚本的调用者、函数和源文件； totalScriptDuration 汇总所有超过 5 毫秒的数据。这就是为什么模糊的“React 运行缓慢”会变成具体的文件路径。请检查调用者类型： classic-script or module-script 指出加载时间评估的要点，而 user-callback or event-listener 指向加载完成后运行的某些东西——观察器、计时器、分析监听器（网络开发).

分支 4：是你的还是第三方的？

按来源对脚本归属进行排序。标签管理器、授权平台、会话录制工具和聊天组件都会安装全局监听器，这些监听器会在每次点击时优先于你的监听器运行。如果第三方来源出现在超过四分之一的糟糕示例中，那么解决方案首先是商业层面的，其次才是技术层面的：缩小标签的作用域、在交互时加载标签，或者将其移至服务器端。不要为了弥补聊天组件本身就会消耗的 40 毫秒延迟而重构你的处理程序。

分支 5：在实验室中重现该问题，然后修复框架

从中选择 attribution.interactionTarget打开 Chrome 开发者工具，并将 CPU 限速设置为与您的现场设备组合相匹配的数值，然后记录交互过程。查找超过某个任务的情况。 50毫秒，长任务阈值（网络开发），并通过 yield 将其拆分。

船 scheduler.yield() 并设有备用方案。Chrome 和 Edge 从 129 版本开始支持，Firefox 从 142 版本开始支持，但是 Safari 在桌面版或 iOS 版上均不支持。MDN 将其标记为有限可用性，而不是基线（免打扰, 我可以用吗对于iOS用户份额较大的土耳其或海湾地区用户而言， setTimeout 备用方案并非可选项。

分支6：衡量你实际销售的市场

全球 CrUX 平均值掩盖了真正能为你带来收益的市场。CrUX BigQuery 数据集发布了国家/地区表—— chrome-ux-report.country_tr.YYYYMM 对于土耳其，任何两位字母的国家代码都采用相同的模式——每月更新，尺寸包括设备外形尺寸和有效连接类型（Chrome 开发者版公共 CrUX API 不公开国家/地区信息，因此此切片仅适用于 BigQuery。

针对您销售的每个市场，将您的产品源与相应的国家/地区表进行比对。一家服务于土耳其、德国和海湾地区的零售商经常会发现，由于设备组合和网络状况不同，基于同一代码库却存在三种不同的 INP 发行版。应该针对收入最高的市场进行优化，而不是仅仅关注您办公室所在的市场。

分支7：证明它移动了什么东西

将此修复视为一项实验，而不是正式部署。 趋势醇一家土耳其电商平台追踪到一个 963 毫秒的移动端 INP 事件，发现是由 React 组件内部 IntersectionObserver 回调导致的一个耗时 700-900 毫秒的任务引起的，该回调延迟了状态更新。 scheduler.yield()并在六个月内将第 75 百分位 INP 从大约 1,400 毫秒降低到大约 650 毫秒。其 A/B 测试结果显示…… 每次会话中，从商品列表到商品详情页的点击率提升 1%。 (网络开发). redBus 将延迟加载交互的延迟从 870–900 毫秒缩短到 350–370 毫秒，文本输入交互的性能提升了 72%，并报告了…… 整体销售额增长7% (网络开发).

请注意，这里使用的是真实的比例：1%，而不是 40%。这就引出了一个值得纠正的数字。

8.4%这个数字需要加以说明。

该领域最常被引用的数据是，移动速度每提高 0.1 秒，零售转化率就能提高 8.4%，旅游转化率就能提高 10.1%。这一数据来自一项真实的研究——由 55 和德勤受谷歌委托，涵盖 37 个品牌，超过 30 万次会话（网络开发但它测量了页面加载时间和服务器延迟等负载指标， 非INP数据涵盖2019年底的30天；且没有对照组，因此这只是观察到的相关性，而非因果效应。可将其用于展开预算讨论，而非预测交互延迟修复的回报。

【需要内部数据：Switas 在客户项目中实施前后的第 75 页 INP 和转化率变化数据，以用第一方证据替换公开案例研究。】

这个决策树哪里出了问题？

  • 低流量来源。 在数据量稀少的情况下，第 75 百分位数属于噪声。如果每个模板每周的交互次数低于大约 1,000 次，则需要在实验室进行分析，并接受无法在 CrUX 中验证结果的事实。
  • Safari 和 Firefox 用户将不可见。 CrUX 仅支持 Chrome 浏览器。如果您的收入中有相当一部分来自 iOS Safari 浏览器，则说明您的 INP 数据所反映的用户群体您并未全面衡量。
  • 滚动卡顿不在讨论范围内。 INP 忽略滚动，因此该树永远不会发现无限滚动列表的问题，这种列表虽然感觉很糟糕，但测试结果为绿色。
  • 它发现的是延迟，而不是设计缺陷。 在令人困惑的筛选面板上进行 180 毫秒的交互是一个用户体验问题，而这个树状结构无法识别。

常见问题解答

INP 和第一输入延迟是同一回事吗？
不。FID 仅测量首次交互处理程序运行之前的延迟。INP 则涵盖了整个访问过程中典型交互的完整延迟，包括处理程序的执行和后续的渲染过程。

为什么我的 Lighthouse 评分看起来正常，而 INP 却显示红色？
Lighthouse 是一款实验室工具，无法测量 INP（实际用户操作次数），因为它没有真实用户进行任何操作。诸如总阻塞时间之类的代理指标相关性不高。建议您查看 PageSpeed Insights 的字段部分。

CrUX多久才能修复这个问题？
CrUX 报告基于 28 天滚动窗口，而 BigQuery 表每月发布一次。预计大约四周后会收到部分信号，并在两次月度发布后获得完整数据。

我可以在不修改框架的情况下修复 INP 问题吗？
通常是这样。Trendyol 的解决方案是在 React 16.9 的一个回调函数内部使用 yield，无需升级。延迟加载第三方标签也与框架无关。

同意横幅会影响 INP 吗？
这可能通过两种方式实现：横幅广告自身的脚本会在加载期间争夺主线程，而且用户同意后通常会立即触发标签加载的激增。因此，应单独衡量用户同意后的首次交互。

我需要 RUM 供应商吗？还是 web-vitals 库就足够了？
归因模型加上一个信标端点就足以运行这套系统。供应商购买的是留存率、细分和仪表盘，而不是更优质的归因数据。

我应该针对搜索引擎优化 (SEO) 还是转化率优化 INP？
以转化率为导向。核心网页指标是排名信号，但已记录的商业案例——Trendyol 为 1%，redBus 为 7%——是互动质量带来的影响，这些影响本身就足以证明这项工作的价值。

在您自己的列表页面上运行此操作

使用流量最高的模板，为其添加归因模型，并按顺序遍历分支 0 到 7。如果您希望使用包含国家/地区切片和实验设计的字段数据运行决策树，我们的 网站性能团队 正是这种参与方式。

来源

相关文章

Switas 见闻

雅虎财经 今日美国 Benzinga 商业内幕 晨星 市场 长桥
Magnify：利用 Engin Yurtdakul 扩大影响力营销

查看我们的微软 Clarity 案例研究

我们重点介绍了 Microsoft Clarity，它是一款由真正了解像 Switas 这样的公司所面临挑战的产品开发人员，以实际应用场景为导向打造的产品。诸如“愤怒点击”和 JavaScript 错误跟踪等功能，在识别用户痛点和技术问题方面发挥了至关重要的作用，从而能够进行有针对性的改进，直接提升用户体验和转化率。