“与下一个油漆的交互(INP):完整的技术指南和优化标准”
Next Paint 交互 (INP) 是 Google Core Web Vital 官方指标,用于评估网页的整体界面响应能力。
与仅评估页面加载时的初始交互的首次输入延迟 (FID) 不同,INP 会观察用户访问页面的整个生命周期中发生的所有用户交互(点击、敲击和键盘输入)的延迟。
答案优先摘要
下次绘制交互 (INP) 是一项核心 Web 重要指标,用于测量从用户与页面交互(单击、点击或按键)到浏览器在屏幕上呈现更新的视觉框架所花费的时间。INP 延迟由三个子部分组成:输入延迟、处理持续时间和呈现延迟。在真实用户访问的第 75 个百分位处,通过的 INP 分数为 200 毫秒或更短。2024年3月,INP正式取代Google搜索排名算法中的首次输入延迟(FID)。
INP 分数阈值和评级量表
为了提供响应式用户体验,网页必须满足以下 INP 核心 Web 生命阈值(在真实用户现场访问的第 75 个百分点进行评估):
- 好:$\le 200\text {ms} $(绿色)- 快速、流畅的 UI 响应,让用户感觉是即时的。
- 需要改进:$> 200\text {ms} $ 和 $\le 500\text {ms} $(琥珀色)- 在影响用户参与度的点击或点击过程中出现明显延迟。
- 差:$> 500\text {ms} $(红色)- 严重的界面冻结和主线程阻塞,导致用户沮丧和高跳出率。
| INP 延迟 | 绩效评级 | 用户体验影响 | Google 搜索排名状况 |
|---|---|---|---|
| $\le 200\text {ms} $ | 好 | 点击或单击即可获得即时视觉反馈。 | 核心 Web Vitals 评估全部及格。 |
| $201\text {ms} - 500\text {ms} $ | 需要改进 | 交互滞后;更新 UI 状态有明显延迟。 | 可能会因竞争性关键词而遭受排名处罚。 |
| $> 500\text {ms} $ | 可怜 | 按钮无响应、UI 冻结和主线程死锁。 | 未通过核心网络生命评估;主动排名惩罚。 |
INP 交互延迟的三个组成部分
当用户与网页上的元素交互时,INP 测量的总交互延迟由三个连续阶段组成:
- 输入延迟:从用户启动物理交互(单击、敲击或按键)到浏览器主线程开始执行关联的事件处理程序之间所经过的时间。输入延迟主要是由页面加载或组件重新渲染期间运行的长后台 JavaScript 任务导致的主线程拥塞引起的。
- 处理持续时间:在该交互的所有注册事件侦听器中执行 JavaScript 代码所花费的时间(例如
onclick、onkeydown或框架反应式状态更新处理程序)。 - 呈现延迟:事件处理程序完成后,直到浏览器完成计算样式重新计算、布局、绘制更新的像素以及在用户的显示硬件上显示下一个视觉帧所花费的时间。
从数学上讲,单次交互的总 INP 延迟表示为:
$$\text{INP 延迟} = \text{输入延迟} + \text{处理持续时间} + \text{呈现延迟}$$
为什么 Google 在 2024 年 3 月用 INP 取代了 FID
首次输入延迟 (FID) 仅测量页面上第一次交互的输入延迟部分。虽然 FID 有助于识别主线程阻塞阻止初始交互的页面,但它面临两个主要的技术限制:
- 单交互范围:FID 忽略页面加载后的所有后续用户交互,未能捕获复杂的单页面应用程序 (SPA) 客户端导航期间的缓慢情况。
- 不完整的延迟测量:FID 仅测量输入延迟,完全忽略处理时间和呈现延迟。如果初始输入延迟低于 50 毫秒,则执行时间为 2,000 毫秒的事件处理程序会收到通过的 FID 分数。
2024年3月,Google正式用INP取代FID作为官方Core Web Vital排名因素。INP 评估会话期间所有交互的 75%,为现代 Web 应用程序的真实用户体验提供更全面、更现实的评估。
合格的用户交互与非合格的事件
INP 测量离散的用户交互,其中用户期望立即视觉反馈。了解哪些相互作用计入 INP 对于诊断分析至关重要:
测量交互
- 鼠标单击:单击按钮、链接、表单控件或自定义交互组件。
- 触摸屏点击:点击移动设备或平板电脑上的元素。
- 键盘按下:按下物理或虚拟键盘键(例如
Enter、Space或文本输入中的字母数字键)。
非测量事件
- 滚动和平移:滚动页面或平移地图组件不会触发 INP 测量。
- 悬停:将鼠标光标移动到元素上而不单击,不包括在 INP 中。
- 页面加载动画:无需用户输入即可自动触发的 CSS 动画不计入 INP。
经验证的技术策略可优化高 INP 分数
为了将 INP 延迟降低到 200ms 阈值以下,工程团队应实施以下技术优化:
- 分解长主线程任务:使用
requestIdleCallback()、setTimeout()或scheduler.yield()将长度超过 50 毫秒的执行任务分解为更小的块,允许浏览器在任务执行块之间立即处理传入的用户输入。 - 优化框架状态更新:在 Vue 3 和 Nuxt 4 应用程序中,使用异步组件边界或延迟反应式引用更新来延迟非关键 UI 重新渲染。
- 最小化布局抖动:避免在改变 DOM 元素后立即读取 DOM 几何属性(例如
offsetHeight或getBoundingClientRect()),这会强制同步布局重新计算。 - 减少 DOM 树深度:过大的 DOM 树会增加呈现延迟期间的样式计算和布局成本。将 DOM 元素总数保持在每页 1,500 个节点以下。
- 优化第三方脚本:大量第三方脚本(分析、广告网络、客户聊天小部件)经常劫持主线程。延迟或网络工作者卸载非必要的第三方脚本。
使用 SimpleOps 进行连续 INP 监控
SimpleOps 通过捕获 Chrome UX 报告 (CrUX) 真实用户现场数据集指标以及综合 Lighthouse 审核来持续跟踪 INP 性能。每当您网站的 75% INP 超过 200 毫秒时,SimpleOps 就会自动提醒您的团队,确保您的应用程序保持快速、流畅并针对搜索引擎排名进行优化。
常见问题解答
有关此主题的常见问题
确保您的网站保持快速运行
SimpleOps 每 60 秒从 15 个以上的全球检查区域持续监控正常运行时间、SSL 安全证书、API 端点和 Core Web Vitals。