Core/Dash 维度： Input Type (INP)

识别哪种用户操作导致了最差的 INP，并优先修复正确的交互处理程序。

免费试用

Trusted by market leaders · Client results

harvardadevintamonarchsnvvpnmarktplaatsaleteianina carekpnfotocasaloopearplugswhowhatwearcompareerasmusmcworkivadpg mediaperionhappyhorizonmy work featured on web.devsaturnebaynestle

维度：Input Type INP (inpit)

Input Type (INP) 维度记录了在用户访问页面期间触发单一最差交互的 DOM 事件类型。该值是来自浏览器 Event Timing API 的原始事件名称：click、keydown、pointerdown、pointerup、keypress 以及其他少数事件。

INP 是一个最坏情况指标。它不平均化交互。它找到从输入到下一次绘制花费最长时间的那一次交互并报告该持续时间。Input Type 维度告诉您用户在那个确切时刻正在做什么。这就是知道“INP 为 450 毫秒”和知道“INP 为 450 毫秒，因为用户在您的搜索字段中进行了输入”之间的区别。

Event Timing API 将相关事件分组为单个逻辑交互。在触摸屏上的点击会将 pointerdown、pointerup 和 click 作为一个组触发。该组内单个最长的事件处理程序决定了交互延迟。CoreDash 会记录最长处理程序的事件类型，也就是导致交互变慢的那个事件。

为什么 Input Type 对 INP 很重要

每种输入类型都映射到您 JavaScript 代码库的不同部分。如果您发现 INP 较差的页面上占主导地位的输入类型是 keydown，您立刻就会知道问题出在击键处理程序中：自动完成、边输入边搜索、每次按键时运行的表单验证。如果看到 click，问题就在您的按钮和链接处理程序中：导航逻辑、状态更新、模态框打开、同步触发的分析调用。

如果没有这个维度，INP 调查将从分析会话、重现步骤以及猜测第 75 个百分位用户尝试进行哪种交互开始。有了 Input Type 维度，您就可以直接跳到相关的处理程序。节省的时间是实实在在的。

Input Type 还能揭示平台差异。一个拥有大量高级用户进行繁重键盘导航的网站将显示出高比例的 keydown 事件导致较差的 INP。主要在移动端使用的产品则会显示 pointerdown 占主导地位。相同的页面，相同的 INP 分数，根据您的实际用户是谁，相同的修复将应用于不同的处理程序。

Input Type 类型

click 与 pointerdown

这些是 CoreDash 数据中最常见的输入类型，约占最差 INP 事件的 75%。在桌面上，click 代表鼠标按键释放。在移动设备上，点击会触发完整的链条：手指触摸屏幕时首先触发 pointerdown，抬起时触发 pointerup，最后触发 click。CoreDash 会记录该链条中拥有最长处理程序的那个事件。

Click 处理程序是繁重的同步 JavaScript 工作的主要位置。对导航项的单次点击可以在同一个任务中触发状态管理更新、DOM 突变、分析事件和重新渲染。在 click 处理程序中进行的每一毫秒同步工作，都会为 INP 增加一毫秒。

解决缓慢 click 处理程序的方法是任务分解。使用 <code>scheduler.yield()</code> 将处理程序分解为更小的任务，并让浏览器在它们之间进行渲染。将分析调用等非关键工作移至零延迟的 setTimeout 中，或将它们完全推迟到 requestIdleCallback 中。浏览器只需要在下一次绘制之前完成影响视觉响应的工作。其他一切都可以等待。

keydown

键盘输入约占 CoreDash 数据中最差 INP 事件的 15%，但它会产生一些最糟糕的分数。原因在于频率：用户在搜索字段中输入时，会在每次击键时触发 keydown。如果您的处理程序耗时 200 毫秒，那么用户在输入每个字符后都会体验到 200 毫秒的延迟。一个 10 个字符的搜索查询就会变成 2 秒的累积阻塞时间。

常见的罪魁祸首是在每次击键时触发同步 API 请求或运行昂贵 DOM diff 的边输入边搜索实现，以及在每次按键时重新检查整个表单的表单验证。这些模式在小规模下运行良好，但在真实用户条件下就会崩溃。

标准的修复方法是防抖和卸载。对搜索处理程序进行防抖处理，使其仅在用户暂停输入后才触发，通常为 200 到 300 毫秒。对于像在大型本地数据集中进行模糊搜索这样更复杂的处理，请将计算移至 Web Worker，以便在每次 keydown 事件之后，主线程保持空闲状态以渲染下一帧。

pointerup

在 CoreDash 数据中，pointerup 事件约占最差 INP 案例的 8%。pointerup 在触摸或点击序列结束时触发，位于 pointerdown 之后。一些框架和 UI 库将其主要的“点击”行为绑定到 pointerup 而不是 click，这会将处理程序提前到交互生命周期的更早阶段。

当 pointerup 显示为主导输入类型时，调查过程与 click 处理程序相同：找出在处理程序中运行了什么 JavaScript，并将必须阻塞下一次绘制的工作与可以推迟的工作区分开来。与 click 的区别通常是一个框架级决策，而不是应用程序级的，因此修复可能涉及调整组件库处理交互绑定的方式。

调试工作流

  1. 在 CoreDash 中按输入类型过滤： 打开失败 URL 的 INP 细分，并检查哪种输入类型在最差交互中占主导地位。如果一种类型占据了超过一半的糟糕 INP 事件，请从那里开始。这种分布告诉您应该将分析时间花在哪里。
  2. 使用正确的交互进行重现： 打开 Chrome DevTools，启用 Performance 分析，并执行 CoreDash 中显示的准确交互类型。由 keydown 主导的页面应通过输入来进行测试。由 click 主导的页面应通过在用户交互的元素上点击鼠标来进行测试。记录跟踪并识别在输入事件之后立即触发的主线程中的长任务。
  3. 应用针对类型的修复并验证： 对于 keydown 问题，添加防抖并重新分析。对于 click 问题，在处理程序的逻辑断点处添加 scheduler.yield() 调用。部署到测试环境，使用带有交互脚本的 WebPageTest 或 Chrome DevTools Performance 面板，并在发布前确认任务持续时间有所下降。

工程经验法则

  • keydown 主导了您糟糕的 INP： 为所有搜索和自动完成处理程序添加防抖。200 毫秒的延迟是标准的起点。如果在该延迟下计算仍然昂贵，请使用 Web Worker 将其移出主线程。
  • click 或 pointerdown 占主导地位： 您的处理程序在浏览器绘制之前执行了过多的同步工作。审计失败 URL 上的每个 click 处理程序。移除同步分析调用。使用 scheduler.yield() 在步骤之间打破多步逻辑。
  • pointerup 占主导地位： 检查您的框架是否将交互逻辑绑定到了 pointerup 而不是 click。修复方法通常与 click 处理程序相同，但代码库中的入口点不同。
  • 混合分布，没有明显的赢家： 问题不在于一种交互类型。对所有类型中最慢的三个独立交互进行分析，并按影响程度逐一解决。不要凭空进行优化。

Input Type 是一个路由信号。它不会告诉您什么是慢的。它只会告诉您往哪里看。一旦您知道当 INP 崩溃时您的用户是在点击、输入还是轻触，随后的每一个调查步骤都会变得更快、更有针对性。