告别FID：INP时代全周期交互响应的优化实战与数据对比
2024年3月，Google 正式用 INP (Interaction to Next Paint) 取代了运行了多年的 FID (First Input Delay)。我在维护一个日活 50 万的 SaaS 后台时，第一时间感受到了这个变化。之前 FID 一直绿油油的 20ms，但用户还是抱怨“表格筛选卡顿”、“保存按钮点了没反应”。切换到 INP 测量后，数据直接红给看：INP 高达 450ms。
FID 只测量“第一次”交互的延迟，且只计算从输入到主线程开始处理的时间，不关心处理结果渲染出来的耗时。INP 则是全周期监控，从点击开始，到浏览器把下一帧画出来为止。对于 SPA 应用，FID 完全掩盖了复杂组件更新时的渲染阻塞问题。
实战：优化一个复杂表单的 INP
在我们的订单管理系统中，有一个包含 200 个表单项（动态渲染）的配置页。用户点击“保存”后，由于主线程被大量的 React 状态计算和 DOM 更新阻塞，导致下一帧迟迟画不出来。
优化前，INP 测量逻辑（问题复现）：
// 这是一个典型的导致 INP 劣化的操作
// 用户点击保存后，同步执行大量计算
const handleSave = async () => {
setIsSaving(true); // 触发状态更新
// 模拟一个巨大的循环，阻塞主线程 300ms
// 这在 SPA 中非常常见，比如深拷贝大对象或遍历大列表
const startTime = performance.now();
while (performance.now() - startTime < 300) {
// 阻塞主线程
}
await api.saveData(formData);
setIsSaving(false);
};
优化方案：使用 scheduler.yield() 或 setTimeout 分片
Chrome 115+ 支持 scheduler.yield()，这是目前处理长任务（Long Tasks）的最佳实践。我重构了保存逻辑，把同步的大任务拆散。
// 优化后的代码：使用 scheduler.yield 让出主线程
// 确保在用户交互后，浏览器有机会绘制下一帧
const handleSaveOptimized = async () => {
setIsSaving(true); // 触发 loading 状态
// 将耗时任务分片
const processHeavyData = async (data) => {
let i = 0;
const chunkSize = 10; // 每次处理 10 条
while (i < data.length) {
// 处理一小块数据
processChunk(data.slice(i, i + chunkSize));
i += chunkSize;
// 关键点：让出主线程，给浏览器绘制下一帧的机会
// 如果不这样做，用户会看到页面冻结直到循环结束
await scheduler.yield();
}
};
await processHeavyData(largeDataSet);
await api.saveData(formData);
setIsSaving(false);
};
数据对比：
在 Moto G Power (Android 10) 这种中低端设备上测试：
- 优化前：INP 420ms，TBT (Total Blocking Time) 850ms。用户点击保存，按钮要等 0.4 秒才变色，体验极差。
- 优化后：INP 降至 150ms，TBT 降至 120ms。按钮响应迅速，符合 Core Web Vitals 的“好”标准（<200ms）。
真实排查案例：第三方脚本的“幽灵点击”
有一次线上反馈，用户进入后台首页，还没操作，INP 就已经报红。我通过 Chrome DevTools 的 Performance 面板录制发现，一个埋点脚本在 window.onload 后发起了大量的同步 XHR 请求，并且执行了一段非常重的 DOM 查询脚本，占用了主线程 600ms。
解决方式：
- 将该脚本标记为
async 并延迟到 load 事件之后执行。
- 使用 Partytown 将第三方脚本隔离到 Web Worker 中运行。
<!-- 之前 -->
<script src="https://analytics-vendor.com/heavy-script.js"></script>
<!-- 之后：使用 Partytown 配置 -->
<script>
window.partytown = {
forward: ['gtag', 'dataLayer'], // 转发函数调用到 worker
};
</script>
<script src="/~partytown/partytown.js" async></script>
<!-- 这个脚本在 worker 里跑，不阻塞主线程交互 -->
<script type="text/partytown" src="https://analytics-vendor.com/heavy-script.js"></script>
这次改动后，首页的 INP 从 320ms 直接掉到了 90ms。INP 时代，任何阻塞主线程的第三方脚本都是性能杀手，必须零容忍。
某百万DAU电商首屏LCP从4.2s到1.8s的优化全记录
去年双十一大促前，我接手了一个核心的电商落地页项目。当时线上数据显示，移动端 LCP 中位数高达 4.2s，远超 2.5s 的及格线。这意味着超过一半的用户看到商品主图需要等 4 秒多，转化率自然惨不忍睹。
经过两周的死磕，LCP 压到了 1.8s。以下是具体的实战步骤。
1. 精准锁定 LCP 元素
用 WebPageTest 跑了一下，发现 LCP 元素不是图片，而是首屏那个巨大的促销标题文本块（因为字体加载慢，或者被巨大的 CSS 阻塞了）。
排查代码：
// 在 Chrome DevTools 控制台运行，找出 LCP 元素
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('LCP Candidate:', entry);
// 打印出是哪个元素
console.log('Element:', entry.element);
}
}).observe({type: 'largest-contentful-paint', buffered: true});
2. 优化手段：预加载与图像压缩
我们的商品图之前是 1200x1200 的 WebP，虽然格式对了，但尺寸没控制好。我写了一个 Node.js 脚本，配合 Sharp 库，在服务端实时生成 640w 的 AVIF 格式（比 WebP 再小 20%）。
关键代码：服务端动态裁剪与 CDN 配合
const express = require('express');
const sharp = require('sharp'); // 版本 0.32.x
const app = express();
app.get('/image/optimize', async (req, res) => {
const { url, width } = req.query;
try {
// 从源站获取图片
const response = await fetch(url);
const buffer = await response.buffer();
// 动态处理：根据请求的宽度生成 AVIF
// 为什么这么做？因为电商图尺寸多变，不能只靠前端 <img> 的 srcset
// 服务端直接吐出最优格式，减少浏览器解码压力
const optimized = await sharp(buffer)
.resize(parseInt(width) || 640)
.avif({ quality: 65 }) // AVIF 质量 65 已经非常清晰
.toBuffer();
res.set('Content-Type', 'image/avif');
res.set('Cache-Control', 'public, max-age=31536000, immutable');
res.send(optimized);
} catch (err) {
res.status(500).send('Error processing image');
}
});
前端配合：
<!-- 关键：使用 fetchpriority="high" 告诉浏览器这是核心资源 -->
<!-- 之前我们只是普通的 <img>，浏览器优先级是 Low -->
<picture>
<source srcset="/image/optimize?url=xxx&width=640" type="image/avif">
<img
src="/image/optimize?url=xxx&width=640"
alt="Product Image"
fetchpriority="high"
width="640"
height="640"
style="content-visibility: auto;"
>
</picture>
3. 消除渲染阻塞：CSS 内联与预连接
排查发现，首屏的 CSS 文件有 180KB，且是同步加载的。LCP 元素（那个大标题）的渲染被 CSSOM 构建阻塞了。
解决方案：
- 把首屏关键 CSS（大约 14KB）直接内联到 HTML 的