用户点击按钮后页面迟迟没有变化、输入时文字卡住、菜单展开不顺，通常都与交互期间的脚本执行、布局计算或渲染有关。
要从真实交互记录中定位最慢场景，再拆解输入延迟、事件处理和展示延迟，而不是只看总包体积。
01 用真实用户数据找到高风险交互
按页面、设备、版本和交互类型分析，不要只看全站一个数字。搜索、筛选、菜单、表单和复杂编辑器往往表现不同。
实验室复现用于定位，现场数据判断影响范围。
02 长任务要拆开并主动让出主线程
大量循环、数据处理、组件更新和同步解析会连续占用主线程。将工作切成较小任务，允许浏览器在中间响应输入和绘制。
能延后、缓存或移到后台线程的工作不要挤在点击之后。
03 事件处理只做当前必须的事
按钮点击后先给出可见反馈，再处理非关键统计、预取和复杂计算。避免一个事件触发多层重复监听和无关状态更新。
防抖与节流要按任务设计，不能造成用户输入被吞。
04 减少不必要的渲染与布局
大型列表、复杂DOM、频繁读取和写入布局、组件级联更新都会拉长反馈。使用虚拟化、局部更新和稳定组件边界。
动画优先使用高效属性，并避免在交互中触发大范围重排。
05 审计第三方脚本与框架开销
聊天、分析、广告和标签管理可能在用户操作时执行。确认加载时机、事件数量和业务价值。
框架本身不是唯一原因，组件结构和数据流同样需要分析。
06 立即反馈与最终完成可以分开
对于耗时操作，点击后先显示按下、加载或乐观状态，让用户知道系统已接收；随后完成请求和最终更新。
反馈不能掩盖失败，仍需提供错误与恢复。
INP诊断三阶段
阶段 | 常见瓶颈 | 优化方向 |
|---|---|---|
输入延迟 | 主线程已有长任务 | 拆分/延后后台工作 |
处理时长 | 事件函数执行过多 | 精简处理、缓存、Worker |
展示延迟 | 渲染与布局过重 | 局部更新、虚拟化、减少DOM |
常见问题
INP多少算好？
常用目标是在真实用户75百分位下不超过200毫秒，但应优先改善最影响业务的交互。
减少JavaScript包体就能改善INP吗？
有帮助但不充分，交互时的执行方式、渲染和第三方任务更关键。
防抖会提升INP吗？
可能减少频繁工作，但过长延迟会让界面显得迟钝，应按输入场景设置。
服务端渲染能解决INP吗？
主要改善初始内容，不会自动解决客户端交互中的长任务。
如何找到具体慢交互？
结合真实用户监测、Performance记录和用户操作路径复现。
链接复制成功
