为什么网站点击后变慢：检查并优化INP

筛选条件迟迟不生效、菜单不能立即打开，或输入的文字延后显示，即使页面加载很快，也可能出现这些问题。应检查操作后的响应和 JavaScript 处理。对于使用 Worker 或 iframe 的应用，还要分析消息交换。

为什么快速网站对操作的响应可能很慢

单击后，浏览器需要处理该事件，执行 JavaScript 并显示更新后的帧。如果主线程繁忙，则有些工作会等待。因此，良好的加载速度并不能保证菜单、过滤器和表单的快速响应。

将计算移到 Web Worker 可以减轻主线程的负担，但也增加了数据交换。页面窗口、Worker 和 iframe 通过 postMessage() 交换消息。消息发送后，也可能需要排队等待处理。

从三个可能的原因开始：

例如，用户每输入一个字母，搜索就向 Worker 发送一次请求。如果上一轮搜索结果尚未算完，后续请求便会积累。用户已经完成输入，应用却仍在计算旧输入的结果。应测量消息频率、处理时间和传输量。

INP（Interaction to Next Paint）评估访问期间页面对点击、触摸和键盘输入的响应能力。按照异常值排除规则，结果反映较慢交互中的一次。单次交互延迟包括等待处理开始、执行事件处理程序，以及等待下一帧显示的时间。

良好的 INP 为 200 毫秒及以下；超过 200 毫秒、但不超过 500 毫秒时需要改进；超过 500 毫秒则较差。评估网站时，应分别查看移动设备与桌面设备上，各次访问 INP 的第 75 百分位数。

当消息队列的处理占用主线程并干扰输入或渲染时，消息队列可能会导致这种延迟。但Worker响应时间不能自动被视为INP。

让我们回到搜索：输入的字母可能会立即出现，稍后会更新结果。尽管有用的工作尚未完成，但下一帧已经显示。在这种情况下，请分别测量对输入的响应和获得实际结果的时间。快速加载指示器并不能证明搜索本身变得更快。

INP检查有助于调查测试运行中的交互延迟。选择存在问题操作的页面：菜单、目录、表单或购物车。在报告中，检查哪些交互已完成以及发现了哪些延迟原因。结论适用于本次运行及其条件。

JS Scanner 分析 Chromium 中单次页面加载时的 JavaScript，不执行点击或滚动。报告展示脚本大小与加载、代码执行、长任务、错误，以及主机名不同的脚本。网站提供可用的源码映射时，还能查看打包文件内部的模块。

比较报告以选择要检查的区域。 JS Scanner 中的重文件可能可以解释启动页面时的负载，但它的存在尚不能证明点击缓慢的原因。加载后的行为需要单独重现。这两种工具都可以帮助您缩小搜索范围；它们不提供所有窗口和Worker之间的每条消息的跟踪。

单击后或在其他页面状态下可能需要加载期间未执行的代码。删除前请检查这些脚本。具有不同主机名的脚本也不一定是多余的：项目自己的 CDN 可以属于这一组。

记录复现步骤。指定页面、设备和界面状态。例如：打开目录，快速输入查询，然后选择过滤器。
如果存在 RUM 或 CrUX，请使用真实访问数据选择最明显的问题。实验室运行并不能取代真实访问的统计数据。
运行 INP 检查并将报告覆盖范围与有问题的活动进行匹配。如果还没有重现，请在浏览器中单独检查。
探索通过 JS Scanner 加载 JavaScript。选择可疑文件和可能与延迟重叠的长任务。
在 DevTools 中记录有问题的场景。对于 Worker 或 iframe，跟踪正在发送的消息、已启动的处理、响应和屏幕刷新。请求 ID 将有助于区分对旧输入的响应和当前输入的响应。
修复后，使用相同的设备、CPU 和网络设置重复相同的步骤。比较多次运行，然后检查累积的真实访问数据。