Core/Dash 维度： 输入类型 (INP)

维度：输入类型 INP (inpit)

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

INP 是一个最坏情况指标。它不会对交互进行平均计算。它找出从输入到下一次绘制耗时最长的那次交互，并报告该持续时间。输入类型维度告诉您在那个确切时刻用户正在做什么。这就是知道“INP 是 450 毫秒”与知道“由于用户在您的搜索字段中输入，INP 是 450 毫秒”之间的区别。

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

为什么输入类型对 INP 很重要

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

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

输入类型还揭示了平台差异。一个有大量高级用户使用键盘导航的网站，将显示高比例的 keydown 事件导致较差的 INP。主要在移动端使用的产品将显示 pointerdown 占主导地位。同样的页面，同样的 INP 分数，根据您的实际用户群体，同样的修复方法可能应用于不同的处理程序。

各种输入类型

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 的边输入边搜索实现，以及在每次按键时重新检查整个表单的表单验证。这些模式在小规模下运行良好，但在真实用户条件下就会崩溃。

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

pointerup

在 CoreDash 数据中，Pointer up 事件约占最差 INP 案例的 8%。pointerup 在触摸或点击序列结束时（即 pointerdown 之后）触发。一些框架和 UI 库将其主要的“click”行为绑定到 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 处理程序相同，但代码库中的入口点不同。
• 混合分布且没有明显的主导者： 问题不在于某一种交互类型。对所有类型中最慢的三个独立交互进行性能分析，并按影响程度依次解决它们。不要进行抽象优化。

输入类型是一个路由信号。它并没有告诉您什么是慢的，而是告诉您该去哪里寻找。一旦您知道了在 INP 较差时用户是在点击、输入还是轻触，后续的每一个调查步骤都会变得更快速、更具针对性。