大多数团队仍然把Core Web Vitals当作一个需要追逐的Lighthouse分数，而不是需要修复的架构问题。这就是为什么一个网站在PageSpeed Insights中能拿到95分，却仍然在Google Search Console的Core Web Vitals评估中不达标。这两个数字衡量的是完全不同的东西，而其中只有一个会影响排名和真实用户体验。
我们不打算给出装插件之类的建议。如果你对性能问题的解决方案是“装一个缓存插件”，那你解决的是症状，而不是病因。下面来看看真正影响每项指标的因素，以及实验室数据和真实用户数据为什么经常对不上——对不上到你不能只信任其中一个的地步。
LCP是关键路径问题，不是图片问题
Largest Contentful Paint（最大内容绘制）衡量的是页面中最大可见元素——通常是主图、标题或横幅——完成渲染所需的时间。团队的默认思路是“压缩图片”，这确实有帮助，但过了某个临界点后，图片往往就不再是瓶颈了。
真正的关键路径是这样的：
- 首字节时间（TTFB）。 如果服务器或源站要花上几百毫秒才能响应、让浏览器拿到可处理的内容，那再怎么压缩图片也救不了你。边缘渲染、区域级只读副本，以及把对TTFB敏感的路由迁移到CDN的计算层（Cloudflare Workers、Vercel Edge、Lambda@Edge），都能有效缩短这一时间——具体能缩短多少，很大程度上取决于你的技术栈、所在区域和起始基线。
- 阻塞渲染的CSS和JS。 浏览器在能够绘制页面之前必须解析的每一个样式表和同步脚本，都会把LCP往后推。把首屏内容的关键CSS内联，其余部分延迟加载。
- 资源可发现性。 浏览器的预加载扫描器需要尽早发现你的LCP图片。如果这张图片是由JavaScript注入的、是通过CSS的
background-image加载的，或者藏在客户端的数据请求背后，那你就把发现时间推迟了几百毫秒。请在真正的<img>标签上使用fetchpriority="high"，并为其配上一个<link rel="preload">。 - 字体加载。 如果你的LCP元素是文字，而你加载网络字体时又没有设置回退策略，那就相当于在文字能够绘制之前，多加了一整轮网络往返。
font-display: swap和预加载解决的是问题的两个不同方面：swap会立即用回退字体绘制，让这一轮往返不阻塞LCP（但真正的字体换上时可能引发明显的重排，也就是CLS的代价）；而预加载字体文件本身则缩短了获取时间，让替换更早发生。两者要一起用，而不是二选一。
这些都不是插件里的一个开关能解决的问题。它们是路由、标记顺序和资源提示——是在你的构建流程和HTML里做出的决定，不是在WordPress后台里点一下就行的。
INP：JavaScript架构撑不住规模时会发生什么
Interaction to Next Paint（下一次绘制交互，INP）在2024年3月取代了First Input Delay，成为正式的Core Web Vital指标，而且更难被“钻空子”——因为它采样的是整次访问过程中的每一次交互，而不只是第一次。一个网站完全可能首次点击很快，却依然在INP上不达标：随着组件不断挂载、状态不断累积，后面某一次交互的响应时间长到把p75分数拖了下来——哪怕第一次点击感觉是瞬间完成的。
INP主要受主线程争用支配。浏览器忙于执行JavaScript时，是没法响应一次点击或按键的。常见原因包括：
- 长任务。 任何超过50毫秒的任务都会阻塞主线程处理输入。大规模的状态更新、未经优化的重新渲染，以及同步执行的第三方脚本（聊天插件、统计代码、广告交易平台）是最常见的元凶。
- 水合（hydration）成本。 那些在加载时对整个页面进行水合、而不是渐进式或选择性水合的重客户端框架，恰好会在用户开始交互的那一刻占用主线程。Islands架构（Astro对孤立组件的选择性水合）和可恢复性（resumability，Qwik的做法：将执行状态序列化，恢复时完全不需要重新运行组件逻辑）是针对这一问题的两种不同技术，此外还有React Server Components。如果你的营销网站跑的是一个完全客户端渲染的SPA，INP通常会是最先暴露问题的地方。
- 未合并的事件处理。 一次输入触发多次同步重新渲染、布局重算或API调用，代价会迅速累积。防抖（debouncing）、把非紧急任务交给
requestIdleCallback处理、把重计算挪到Web Worker中，这些都有帮助。 - 第三方脚本数量。 标签管理器一次加载十几个下游脚本，是INP的头号杀手之一，因为你根本控制不了它们的执行成本，能控制的只是它们是否加载、什么时候加载。
代码分割和基于路由的懒加载能减少发送的JS总量，但INP尤其看重的是在交互窗口期间保持主线程空闲——这既是一个包体积问题，也同样是一个调度问题。
CLS在很大程度上仍然是一个自律问题
Cumulative Layout Shift（累积布局偏移，CLS）是三项指标里最容易修复的一个，也是唯一与服务器基础设施完全无关的一个。它通常由以下原因造成：
- 图片和嵌入内容没有设置明确的
width/height，也没有在CSS中预留aspect-ratio。 - 网络字体换入时与回退字体的度量不一致，导致文本重排——可以在
@font-face中用与回退字体匹配的size-adjust来缓解。 - 广告、Cookie提示条，以及在首次布局绘制完成后动态插入的内容，把已有内容往下挤。
- 在已有内容上方插入新内容（一种常见的CMS/个性化错误——页面加载完成后在顶部插入一条横幅）。
只要每个动态元素都预留好空间，几乎任何技术栈都能把CLS控制在0.1以下。缺一个width属性，是没有什么基础设施层面的方案能补救的。
实验室分数与真实用户数据为什么会不一致
这部分是大多数报告都会跳过的内容。Lighthouse和PageSpeed Insights的“实验室”数据，跑的是在一台模拟的中端设备上、在限速网络下、在干净缓存状态下的单次页面加载，不包含任何真实用户的差异性。它是可复现的，这让它很适合用 于回归测试——但它终究只是一张合成的快照。
真实用户数据——也就是Search Console的Core Web Vitals报告和Chrome用户体验报告（CrUX）里显示的数据——是一个28天滚动汇总的第75百分位数值，采集自真实Chrome用户所使用的真实设备、真实网络和真实缓存状态。这才是Google实际用作排名信号的数据。
这种差距会以几种可预见的方式表现出来：
- 设备构成。 你的实验室测试跑在一台固定的模拟设备上。而真实用户数据里包含了跑在4G网络上的真实低端安卓手机，它们的INP表现永远会比合成的中端设备画像更差。
- 第三方脚本的不确定性。 A/B测试、隐私同意管理平台和广告代码，在实验室抓取环境（可能不接受Cookie、不触发地理定位、不加载区域性广告网络）中的触发方式，往往和面对真实流量时不一样。
- 缓存状态。 实验室测试往往是冷启动的。而真实用户在重复访问时会命中你的CDN缓存、预热过的字体和此前加载过的资源，这有时会让真实用户数据工具显示出比实验室数据更好的结果——正好与通常的情况相反。
- 样本量与百分位。 一次实验室跑测只是一个数据点。而第75百分位的真实用户数据意味着，有四分之一的真实访问表现比你看到的数字更差——而这恰恰是那些插件式“快速修复”永远碰不到的长尾部分。
把实验室数据当作CI中的回归门槛，而不是你真实分数的替身。把真实用户数据当作你真正要负责的事实依据，用真实用户监控去诊断它，而不是反复跑Lighthouse。
到底该优先做什么
如果要排优先级：先修CLS（成本最低、把握最大），再修LCP（基础设施和标记层面的改动，前后数字变化清晰可见），把INP当作一个持续存在的架构问题来对待，而不是一次性修完就完事——每上线一个新的第三方脚本，或者组件树变得更重，INP都会再次恶化。
这也是为什么Core Web Vitals的工作应该交给编写和上线代码的人来做，而不是交给一份市场部的检查清单。我们的技术SEO团队把性能当作一个带有排名副作用的工程问题来处理，而不是反过来——因为事情本来就是这样运作的。
总结： 实验室分数告诉你的是，从昨天到今天你有没有把什么弄坏了。真实用户数据告诉你的是，你的用户和Google实际体验到了什么。如果这两个数字对不上，相信真实用户数据——然后去修架构，而不是去调插件设置。
