INP 取代 FID：INP 核心网页指标对你意味着什么

Interaction to Next Paint（INP）于 2024 年 3 月 12 日取代 First Input Delay（FID）成为核心网页指标。简而言之：INP 核心网页指标衡量你的页面在整次访问中对每一次点按、点击和按键做出可见响应的速度——而不仅仅是首次交互之前的延迟。由于它捕捉的是从输入一直到下一帧绘制的完整链条，因此它比 FID 以往任何时候都更难通过。

如果你的网站轻松通过了 FID，但用户仍然反映按钮感觉迟钝，那么 INP 正是这种痛点如今在你的 Search Console 报告中显现之处。本指南将确切解释 INP 衡量什么、为何更严格，以及让你最慢的交互达到 200 毫秒"良好"阈值以内的具体路径。

从 FID 到 INP：到底变了什么

FID——First Input Delay（首次输入延迟）——只衡量浏览器能够开始处理页面上首次交互之前的延迟。它在你的事件处理程序开始运行的那一刻就停止计数。它从不衡量该处理程序耗时多久，也从不衡量浏览器将结果绘制到屏幕上需要多长时间。

这使得 FID 很容易通过。首次交互通常发生得较早，此时主线程有片刻的空闲，因此绝大多数网站即使后续交互感觉已经坏掉，也能得到"良好"的评分。FID 奖励了那些纸面上技术性响应良好的页面，而用户却坐在那里等待菜单打开、等待筛选器生效。

INP 修复了这个盲点。它不再是针对某一次较早交互的单一数字，而是观察整次访问中的每一次点击、点按和按键，并报告其中最差一次的响应性。它衡量的是真实、可感的迟钝，而非一种形式。

Interaction to Next Paint 究竟衡量什么

INP 对单次交互计时，从用户操作的那一刻起，到浏览器绘制反映该操作的下一帧的那一刻止。这个完整的时间窗口分为三个部分，其中任何一个都可能毁掉你的得分：

• 输入延迟（Input delay）——用户操作与你的事件处理程序开始之间的时间。这几乎总是由主线程被其他 JavaScript 阻塞所导致（框架水合产生的长任务、一个分析信标、一个第三方标签）。
• 处理时间（Processing time）——你的事件回调运行所需的时间。点击处理程序内部的繁重工作会直接体现在这里。
• 呈现延迟（Presentation delay）——重新计算样式和布局并绘制最终帧所需的时间。臃肿的 DOM 或昂贵的布局会使这一部分急剧膨胀。

只有离散交互才计入：点击、点按和按键。滚动和悬停被刻意排除在外，因为它们在主线程之外处理，并不是 INP 试图捕捉的对象。

为何 INP 核心网页指标比 FID 更严格

三个设计上的选择使 INP 核心网页指标比 FID 确实更难满足：

1. 它监测的是整次访问，而非首次点按。你的 JavaScript 仍在忙于水合的那一次交互，或者下拉菜单重新渲染了上千行的那一次交互，恰恰正是 INP 很可能会报告的那一次。
2. 它衡量的是完整链条，而不只是延迟。处理时间和呈现延迟对 FID 是不可见的。而在 INP 下，它们占了方程式的一半。
3. 阈值对应的是更长的链条。FID 将 100 毫秒视为"良好"，超过 300 毫秒视为"差"。INP 则是 200 毫秒或以内为"良好"，200–500 毫秒为"需要改进"，超过 500 毫秒为"差"。数字更大了，但它现在必须涵盖多得多的工作。

实际效果是：以接近 100% 的通过率通过 FID 的网站，在 INP 上经常不及格。迟钝的折叠面板、卡顿的数量调节器、每次按键都会结巴的搜索框——这些一直都是坏的，而现在它们被衡量了。

INP 核心网页指标是如何衡量的

INP 是一项字段指标（field metric）。它来自 Chrome 用户体验报告（CrUX）中的真实用户，在各次页面加载中以第 75 百分位进行汇总——因此必须有四分之三的访问达到你的目标，该 URL 才能通过。你无法在受控的实验室环境中造假，因为它需要真实的人类交互。

在整次访问中，INP 并非在高流量页面上简单地取你最差的那一次交互。它容忍离群值：对于有许多交互的页面，它大约每 50 次交互忽略一次极端峰值，并报告次差的那一次。不过在只有少数几次交互的典型页面上，你最差的那一次就是你的 INP。

由于实验室工具无法触发真实输入，在开发时可使用 Lighthouse 中的 Total Blocking Time（TBT，总阻塞时间）作为粗略的替代指标。较高的 TBT 几乎总是预示着较差的 INP，因为两者都由长时间的主线程任务驱动。

达到 200 毫秒以内的实用路径

要达到 200 毫秒阈值以内，几乎总是关于释放主线程并缩短输入与绘制之间的工作。大致按优先级排序：

• 拆分长任务。任何超过 50 毫秒的任务都会阻塞输入。拆分繁重的工作，并在可用时使用 scheduler.yield()（或退而使用 setTimeout 作为后备）在各段之间将控制权交还给浏览器，以便待处理的点击能够被处理。
• 发送更少的 JavaScript。按路由进行代码拆分，延迟加载非关键脚本，并移除未使用的打包代码。被解析和执行的脚本越少，意味着输入延迟越短。
• 审查第三方标签。标签管理器、聊天挂件、A/B 测试工具和分析工具是 INP 的常见罪魁祸首。延迟加载它们，并舍弃那些你无法证明其价值的。
• 先绘制反馈，再做繁重工作。在处理程序内部更新可见状态（高亮按钮、显示加载指示器），然后将昂贵的工作推迟到稍后的帧。即使完整结果需要更长时间，用户也能立即看到响应。
• 将计算转移到 Web Worker。筛选、排序和解析大型数据集完全应当在主线程之外进行。
• 削减渲染成本。缩小 DOM，避免布局抖动，并使用 CSS 的 content-visibility 来跳过渲染屏幕外的内容——这直接攻克呈现延迟。
• 使用你的框架的并发工具。在 React 中，useTransition 和 useDeferredValue 可以在较繁重的更新于后台渲染时，保持紧急输入的响应性。

如何诊断你的 INP 问题

去修复那些真正伤害到真实用户的交互，而不是那些最容易找到的。从字段数据由外向内着手：

• PageSpeed Insights 和 Search Console 核心网页指标报告会告诉你哪些 URL 组在字段中 INP 不及格，以及在哪种设备类型上。
• web-vitals JavaScript 库（attribution 构建版）是最有用的单一工具。它不仅报告 INP 数值，还报告被交互的确切元素，以及在输入延迟、处理和呈现三者之间的细分——这样你就知道该攻克这三个部分中的哪一个。
• Chrome DevTools 性能面板让你能够录制一次缓慢的交互，并逐帧查看长任务，精确定位到负有责任的脚本或回调。

请在中端移动设备上或使用 CPU 节流来复现。那些在高速笔记本电脑上不可见的 INP 失败，在你大多数流量所使用的手机上却痛苦地真实存在。

INP 只是排名全局中的一块拼图

响应性很重要，但要把握好分寸。核心网页指标是一个轻量级的排名信号，也是可比较页面之间的决胜因素——它们不会把单薄的内容抬高到优质内容之上。INP 最好被视为一条用户体验的底线：达到 200 毫秒以内，这样速度就永远不会成为一个优质页面表现欠佳的原因，然后把你剩余的精力投入到内容质量、相关性和权威性上。

品牌实力与这一切并驾齐驱。一个快速的网站仍然需要一个人们信任并记得住的名字。如果你正在挑选域名，像 Atom.com 这样经过精选的市场是寻找优质、适合品牌化名称的绝佳起点——每个刊登都附带免费的 AI 估价、USPTO 商标查核、安全的第三方托管，以及一个设计好的标志，这消除了挑选一个能让买家认真对待的名字时的许多猜测。一个技术上出色的网站配上一个令人过目即忘的域名，只完成了一半的工作。

常见问题

INP 是什么时候取代 FID 成为核心网页指标的？

INP 于 2024 年 3 月 12 日正式取代 FID。它在 2023 年 Google I/O 上作为未来的替代品被宣布，并在切换之前作为一项待定指标运行，给团队留出了准备时间。

多少的 INP 得分算好？

在真实用户访问的第 75 百分位处，INP 为 200 毫秒或更少即为"良好"。200–500 毫秒为"需要改进"，任何超过 500 毫秒的都为"差"。由于 INP 使用字段数据，必须有四分之三的访问达到你的目标才能通过。

为什么 INP 比 FID 当年更难通过？

FID 只衡量首次交互开始处理之前的延迟。INP 则衡量整次访问中的每一次交互，并包含处理时间和绘制结果所需的时间——因此它捕捉到了 FID 在结构上无从察觉的迟钝。

我能在 Lighthouse 这样的实验室工具中衡量 INP 吗？

不能直接衡量，因为 INP 需要真实的人类交互。在开发期间使用 Total Blocking Time 作为实验室替代指标，并依靠 CrUX 字段数据、PageSpeed Insights 和 web-vitals attribution 构建版来获取实际的 INP 数值。

导致 INP 不佳的最大单一原因是什么？

阻塞主线程的长 JavaScript 任务。当线程繁忙时——通常是由于框架水合或第三方脚本——浏览器无法及时处理交互，从而拉高输入延迟。拆分长任务并将控制权交还给主线程，通常是影响最大的修复方法。