Core/Dash 维度： Input Type (INP)

维度：Input Type INP (inpit)

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

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

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

为什么 Input Type 对 INP 很重要

每种输入类型都对应你 JavaScript 代码库的不同部分。如果在一个 INP 很差的页面上，你看到 keydown 是主要输入类型，你会立刻知道问题出在你的按键处理程序上：自动补全、边打字边搜索、在每次按键时运行的表单验证。如果你看到的是 click，问题就在你的按钮和链接处理程序上：导航逻辑、状态更新、模态框打开、同步触发的分析调用。

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

输入类型还揭示了平台差异。如果一个网站的高级用户大量使用键盘导航，你会看到高比例的 keydown 事件导致了糟糕的 INP。主要在移动端使用的产品会显示 pointerdown 占主导地位。相同的页面，相同的 INP 分数，根据你的实际用户是谁，相同的修复方法将应用于不同的处理程序。

输入类型

click 和 pointerdown

它们是 CoreDash 数据中最常见的输入类型，约占最差 INP 事件的 75%。在桌面端，click 代表鼠标按钮释放。在移动端，一次轻触会触发完整的事件链：手指接触屏幕时首先触发 pointerdown，抬起时触发 pointerup，最后触发 click。CoreDash 会记录该事件链中处理程序最长的那个事件。

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

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

keydown

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

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

标准的修复方法是防抖和卸载。对你的搜索处理程序进行防抖处理，使其仅在用户暂停打字后触发，通常是 200 到 300 毫秒。对于跨大型本地数据集进行模糊搜索等更复杂的处理，请将计算移至 Web Worker，以便 main thread 保持空闲，能在每次 keydown 事件后渲染下一帧。

pointerup

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

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

调试工作流

1. 在 CoreDash 中按输入类型过滤：打开未通过测试的 URL 的 INP 细分数据，检查哪种输入类型在最差交互中占主导地位。如果一种类型占了糟糕 INP 事件的一半以上，就从那里开始。分布情况会告诉你该把性能分析的时间花在哪里。
2. 使用正确的交互进行重现：打开 Chrome DevTools，启用性能分析，并执行 CoreDash 中显示的确切交互类型。由 keydown 主导的页面应该通过打字来测试。由 click 主导的页面应该通过鼠标点击用户交互的元素来测试。记录轨迹并找出在输入事件发生后立即触发的 main thread 中的 long task。
3. 应用特定类型的修复并验证：对于 keydown 问题，添加防抖并重新进行性能分析。对于 click 问题，在处理程序的逻辑断点处添加 scheduler.yield() 调用。部署到测试环境，使用 带有交互脚本的 WebPageTest 或 Chrome DevTools Performance 面板，并在发布前确认任务时长有所下降。

工程经验法则

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

输入类型是一个路由信号。它不告诉你什么是慢的。它告诉你该看哪里。一旦你知道当 INP 崩溃时用户是在点击、打字还是轻触，后续的每一步调查都会变得更快、更有针对性。