Google把网站排名和这3个数字挂钩，90分以下直接降级

2024年3月，一个安静的更新让无数技术团队连夜加班——INP（Interaction to Next Paint，交互到下一次绘制的时间）正式取代FID（First Input Delay，首次输入延迟），成为Google衡量网站体验的核心指标。很多人到现在还没反应过来：你的搜索排名，正在被这三个数字悄悄决定。

低于50分，SEO（搜索引擎优化）直接受损；冲到90分以上，排名获得加权。这不是建议，是游戏规则。更麻烦的是，大多数开发者严重低估了INP的破坏力——它测量的是用户点击按钮后，到页面真正响应之间的完整延迟，包括事件处理和渲染，比FID严苛得多。

想知道自己站多少分？别信本地测试。

打开pagespeed.web.dev，输入真实URL。这里同时显示实验室数据（Lighthouse模拟）和实地数据（真实Chrome用户的访问记录）。Google排名用的是后者——你的MacBook Pro跑出来的90分毫无意义，北京用户用三年前的安卓机加载你的页面，那才叫数。

CI里埋雷：让烂代码进不了主分支

手动测一次容易，持续守住90分难。把Lighthouse CI（持续集成工具）焊进GitHub Actions（代码自动化流程），每次提交自动跑分，不达标直接阻断部署。

配置并不复杂。在仓库里新建.lighthouserc.json，把性能门槛写死：性能总分不得低于0.9，首次内容绘制（FCP）控制在2秒内，最大内容绘制（LCP）2.5秒内，累积布局偏移（CLS）小于0.1，总阻塞时间（TBT）压到300毫秒以下。任何一条红线被踩，构建失败，代码回滚。

这套机制的本质是：把"事后救火"变成"事前拒止"。团队再忙，也没法把烂性能带到线上。

真实用户监控：知道谁在被伤害

实验室数据是彩排，RUM（Real User Monitoring，真实用户监控）才是现场直播。用web-vitals库把指标埋进生产环境，每次用户访问都把CLS、INP、LCP等数据回传到你的分析端。

关键字段包括：指标名称、具体数值、评级（good/needs-improvement/poor）、变化量（delta）、会话ID、导航类型。keepalive: true确保页面卸载时也能把数据送出去——用户关闭标签页前那半秒的体验，同样被记录。

这套数据会告诉你一个残酷事实：你的P90（90分位）用户可能正在经历5秒以上的INP，而你的平均值看起来依然健康。优化资源该投向谁，数据不会撒谎。

LCP优化：让首屏内容抢跑

LCP通常是首屏的大图、标题文字或横幅。浏览器要经历"发现→下载→解码→渲染"四步，任何一环卡壳，分数暴跌。

第一步是给关键资源开绿灯。用link rel="preload"提前声明LCP图片，fetchpriority="high"告诉浏览器这玩意儿优先级最高。如果用了响应式图片，把srcset和sizes一并写进preload，否则浏览器算不出该下哪个版本，预加载失效。

图片格式是另一个战场。AVIF（AV1图像文件格式）比WebP再省50%体积，支持渐进解码。用picture标签做降级：浏览器支持AVIF就走AVIF，不行换WebP，再不行回退JPEG。ImageMagick或Squoosh都能批量转换，构建流程里加一步即可。

但别只顾着压缩。图片的原始宽高必须写在img标签里，否则浏览器预留空间时算错，布局偏移（CLS）直接起飞。很多设计师切图时顺手丢个2000×1000的原图，前端再用CSS缩到800×400——下载量翻6倍，还浪费解码时间。

字体是LCP的隐形杀手。自定义字体如果用了font-display: swap，文字会先以系统字体闪现，再切到目标字体，视觉跳动被计入CLS；如果用block，文字区域空白直到字体到位，LCP被拖长。最干净的方案是子集化（只打包用到的字符）+预加载+可选的font-display: optional——字体3秒内到不了，用户就看系统字体，不再切换。

INP优化：把主线程还给人

INP测量的是用户交互后到下一帧呈现的完整耗时。长任务（Long Tasks）是罪魁祸首——任何占用主线程超过50毫秒的操作，都会让点击、输入、滚动变得黏滞。

拆解长任务最直接的方式是yield（让出）。把同步代码拆成小块，用scheduler.yield()或setTimeout(0)把控制权交还给浏览器，让它有机会处理用户输入。React的Time Slicing、Vue的异步更新队列，底层都是这个逻辑。

事件监听器是另一个重灾区。防抖（debounce）和节流（throttle）能减少执行频率，但更重要的是减少监听器本身的数量。事件委托把几十个按钮的click收拢到父元素，内存占用和注册开销都大幅下降。

第三方脚本往往是INP的"外包杀手"。聊天插件、分析工具、广告SDK，经常在页面加载后批量注册事件、抢占主线程。用Partytown把这些脚本移到Web Worker（浏览器后台线程）里执行，DOM操作通过代理转发，主线程只负责渲染。代价是兼容性调试变复杂，但对INP的提升是量级差异。

骨架屏和渐进式加载能缓解感知延迟，但别把它们当遮羞布。真正的优化是让代码跑得更快，而不是让用户看更久的动画。

CLS优化：停止页面"地震"

CLS测量的是视觉稳定性。图片没预留空间、字体突然加载、广告位动态插入，都会让页面元素乱跳。用户正要点击的按钮突然下移0.5厘米，误触和愤怒同时发生。

所有媒体元素必须带宽高属性。响应式图片用aspect-ratio（宽高比）CSS属性锁定比例，容器用min-height撑出占位。广告位如果尺寸不确定，先用占位符占住最小可能高度，实际内容加载后只扩不缩。

动画是CLS的灰色地带。transform和opacity的变动不计入布局偏移，但width、height、top、left的改动会。把入场动画从"改变布局"换成"改变绘制层"，视觉效果一样，分数天差地别。

缓存策略：让重复访问飞起来

首次访问优化到极致，回头客的体验同样重要。Service Worker（服务工作线程）拦截请求，把静态资源缓存到本地，二次加载走本地磁盘，延迟降到毫秒级。

但缓存不是一劳永逸。版本更新时，旧资源必须及时淘汰。Workbox的缓存策略分几种：Stale-While-Revalidate（先返回缓存，后台更新）、Cache-First（优先缓存，没有才网络）、Network-First（优先网络，失败回退缓存）。静态资源用Stale-While-Revalidate，HTML入口用Network-First，平衡速度和新鲜度。

CDN（内容分发网络）的边缘缓存是另一层加速。把LCP图片、关键CSS推到离用户最近的节点，TTL（生存时间）根据更新频率设定。版本号打在文件名里，更新即换URL，缓存永不过期问题。

2026年的新战场：INP的精细化治理

INP取代FID已满两年，但多数团队的优化仍停留在"减少长任务"的粗粒度阶段。下一步是建立交互热力图：哪些按钮被点击最多？哪些输入框触发最频繁的重新计算？RUM数据按元素维度聚合，找出真正的瓶颈点。

输入延迟（Input Delay）和处理延迟（Processing Delay）在INP中各占多少比例？前者说明主线程繁忙，需要yield；后者说明事件回调太重，需要优化算法或拆异步。用PerformanceObserver（性能观察器）在客户端拆解这两个阶段，针对性下药。

框架层面的优化也在进化。React 18的并发特性、Vue 3的响应式重构、Svelte的编译时优化，都在减少主线程负担。但框架救不了烂代码——一个同步的1000次循环，在任何框架里都是长任务。