Google Core Web Vitals 2026：INP指标优化实战

2024年3月，Google正式用INP（Interaction to Next Paint）替换了FID（First Input Delay）作为Core Web Vitals的三大指标之一。变化之大，让一大批外贸网站措手不及——原本FID合格（只需小于100ms），INP却不合格（要求小于200ms），排名直接受影响。

INP和FID到底有什么区别？

FID只衡量用户第一次交互的延迟时间，比如第一次点击按钮的响应速度。INP则衡量用户在整个页面访问过程中所有交互的延迟——每次点击、每次输入、每次滚动交互都会被记录，取最差的那次（或接近最差的第98百分位）作为INP值。简单说：FID只看起跑速度，INP看全程表现。

一个外贸产品页，用户展开产品参数、切换颜色SKU、点击询盘按钮——每一个交互都会影响INP评分。很多网站FID只有50ms（优秀），但INP高达600ms（差），因为后续交互的处理函数太重了。

INP不合格的3个典型原因

原因一：主线程被JavaScript阻塞。外贸网站经常加载大量第三方脚本——Google Analytics、Facebook Pixel、在线客服、WhatsApp聊天插件——这些脚本在主线程执行时，用户的点击事件只能排队等，INP直接飙升到500ms以上。

原因二：事件处理函数太重。点击加入询盘按钮后，同步执行了DOM操作、数据校验、动画切换、事件埋点——所有逻辑在主线程一次性跑完，页面冻结200-400ms。原因三：渲染更新不及时。即使JavaScript执行很快，如果浏览器没有在下一帧把结果画出来，用户感知到的延迟仍然很大。缺少requestAnimationFrame调度、强制布局重排都会导致这个问题。

技巧一：拆分长任务

用scheduler.yield()或setTimeout(fn, 0)把一个长任务拆成多个小任务，让浏览器有机会在任务间隙处理用户交互。一个300ms的同步函数拆成3个100ms的异步片段，INP从300ms降到150ms。

具体做法是将耗时操作按逻辑分块，每块完成后通过scheduler.yield()让出主线程。对于不支持scheduler.yield的浏览器，可以用isInputPending()判断是否有待处理的用户输入，有则暂停当前任务先响应用户。

技巧二：第三方脚本延迟加载

所有非关键第三方脚本统一用async或defer加载，在线客服和WhatsApp插件等用requestIdleCallback在浏览器空闲时再初始化。实测可以把INP降低100-200ms。

更激进的做法是把统计脚本移到Web Worker中执行。2026年主流浏览器已经支持Worker中的fetch API，完全可以在后台线程完成数据上报，不阻塞主线程的任何交互。

技巧三：事件处理函数瘦身

点击事件只做最关键的操作，比如显示一个loading状态，数据校验、埋点、动画等放到下一帧或Web Worker中异步执行。用户立刻看到反馈，感知延迟大幅降低。

一个询盘按钮的点击处理，正确的做法是：第一步，立即更新按钮状态为已点击（视觉反馈<16ms）；第二步，在requestAnimationFrame中做表单验证；第三步，在Web Worker中做数据上报。用户的感知是点击即时响应，而不是等300ms后按钮才变色。

技巧四：避免强制同步布局

在同一个函数中先读element.offsetHeight再改element.style.height，浏览器被迫立刻计算布局——这叫强制同步布局（layout thrashing），是INP杀手。正确做法是读写分离：先把所有要读的值存到变量里，再统一修改DOM。

在外贸网站建设中，这种情况最常出现在产品列表的筛选和排序功能中：读取所有产品卡片的高度来计算容器高度，同时又在修改卡片的显示/隐藏状态。一次操作可能触发10+次强制布局，INP直接爆炸。

技巧五：用requestAnimationFrame调度渲染

所有视觉更新都通过requestAnimationFrame调度到下一帧执行，确保浏览器以60fps的节奏更新画面，而不是在一个事件处理函数中强制重绘。

INP的衡量标准是Interaction to Next Paint——从用户交互到下一次画面绘制的时间。即使你的JavaScript只执行了50ms，但如果浏览器没有在下一帧把结果画出来，INP仍然算高。requestAnimationFrame确保每帧只做必要的渲染更新，避免不必要的重绘和重排。