INP衡量用户交互后到页面下一次可见绘制更新的延迟，由输入延迟、处理时间和呈现延迟三段构成，取整个页面生命周期内最慢交互（排除1–2%离群值）作为最终值。
INP 不是用来“度量全周期”的指标，它不追踪一次交互的全部业务链路（比如点击→发请求→等响应→更新DOM→动画完成），而是聚焦在**用户操作后到屏幕首次可见更新之间**这段关键延迟——也就是从手点下去，到眼睛看到变化的那段时间。
INP 测的是哪一段“响应”
它把每次交互的延迟拆成三段相加：
- 输入延迟：用户触发事件（如 click）到浏览器开始执行对应回调之间的时间。常见于主线程被长任务阻塞
- 处理时间：事件回调函数本身执行耗时。比如一堆同步计算、DOM 操作、状态更新
- 呈现延迟：回调执行完，到浏览器真正绘制出下一帧（含视觉反馈）的时间。受渲染管线压力、样式重排、布局抖动等影响
这三段总和，就是这次交互的 INP 延迟值。INP 最终取所有交互中延迟最长的那个（对高交互页面会略去最慢的 1–2%），不是平均值，也不是首屏值。
为什么说它反映“全生命周期”的流畅度
因为 INP 不只看第一次点击，而是记录用户在整个访问过程中每一次有效交互（点击、触摸、键盘输入等），并持续观察。哪怕页面加载完成很久，用户滚动到底部点开 FAQ、切换 Tab、输入搜索词，这些都计入统计。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
这意味着：
- 首屏快 ≠ 全程流畅，INP 能暴露“用着用着变卡”的问题
- 静态内容页可能无交互，INP 不适用；但富交互页（管理后台、编辑器、电商详情页）的 INP 值直接体现真实手感
- 它天然排除偶然卡顿（如某次 GC 或网络抖动引发的极端长任务），更贴近绝大多数用户的体感
如何用 INP 定位真实卡点
不能只看最终数值，要结合工具下钻分析：
- 用 Chrome DevTools 的 Performance 面板录制用户操作，筛选 Interaction 轨迹，查看每段耗时占比
- 在 Event Timing API 中调用
performance.getEntriesByType('event')，拿到每个交互的processingStart、processingEnd、duration等字段 - 重点关注 处理时间过长 的回调：是否做了同步 DOM 遍历？是否在事件里直接 setState 大量数据？是否没做防抖的 input 处理？
- 若呈现延迟高，检查是否触发了强制同步布局（
offsetTop、getComputedStyle）、是否 CSS 动画未启用 will-change 或 contain
优化方向紧扣三阶段逻辑
降低 INP 就是分别压缩这三段：
- 减少输入延迟：避免主线程长期占用，拆分长任务，用
setTimeout或queueMicrotask让渡控制权 - 缩短处理时间：精简事件回调，延迟非关键逻辑（用
requestAnimationFrame或setTimeout(..., 0)），对高频事件（如 scroll、input）加节流 - 压低呈现延迟：避免强制重排重绘，用 CSS transform/opacity 做动画，启用
contain: layout style paint隔离渲染影响
达标线是 ≤200ms，超过 500ms 就属于明显卡顿。这不是实验室理想值，而是 Google 实际采集的用户真实场数据基准。
