PageSpeed Insights 首页那个满分，和 Search Console 里 Core Web Vitals 报告的绿不绿，说的不是同一件事：前者是 Lighthouse 在受控环境下对一次加载做的实验室模拟，后者是 Google 从真实用户访问里汇总出来的字段数据，按 URL 组聚合、按 28 天滚动窗口刷新。所以「满分但报告仍红」并不表示工具出错；真正的情况是，你正拿一个单次模拟的分数去解释一份按组统计的滚动报表。要让报告变绿，动作得换成：先在报告里找到被拖红的那一组网址，判断这组共用哪个模板，再看这组的 LCP 是被 TTFB、资源加载还是渲染延迟消耗掉的，然后等窗口滚动过去。
十一月底的一个晚上，我把 PSI 的链接又贴进浏览器跑了一次。98，绿圈。切到另一个标签页，Search Console 的 Core Web Vitals 还是红色，移动端那栏写着「需要改进」，下面挂着四百多个网址。我盯着这两个数字看了半分钟。第一次遇到这种情况时，我甚至怀疑过是不是报告没更新。
后来我才明白，它们本来就可以不一样，而且完全正常。真正的问题是我当时问错了问题：我一直在问「为什么分数和报告不一致」，其实应该问「报告在用谁的数据算，算多长时间」。
页面顶上那个分数，和页面底下的字段数据
同一个 PSI 页面其实提供了两份数据，只是大多数人只看得到上面那份。
顶部那个圆圈是实验室数据。Lighthouse 在模拟的移动设备和限速网络下跑一次，几秒钟出结果。它稳定、可重复、适合做实验：我改动一处，立刻能看到 LCP 从 3.4 秒变成 2.6 秒，前后因果很清楚。
但往下滚，会有一块叫「发现实际用户数据」的区域，数据来自 CrUX，和 Search Console 的报告同源。这块才是 Google 用来判断页面体验的依据。它慢、滞后、受流量影响，但它反映的是真实用户的体验。
所以我的习惯变成了：实验室数据用来验证改动有没有效果，字段数据用来验收。这两类数据更像是分工不同，而非一个快一个慢。拿实验室分数当验收标准，就是用体温计去量血压。
报告是按组算的，你修的是模板
点开红色的那一组，你会看到几条例证网址，旁边有导出按钮，能把整组 URL 拉下来。
我第一次做这件事的时候有点意外。那四百多个网址导出后按路径前缀一排，几乎全落在同一个内容模板上：同一个详情页结构、同一个侧栏、同一段在 head 里同步加载的脚本。Google 把它们归成一组，不是随手分的；在它看来，这些页面的结构足够相似，可以放在一起评估。
这一层的含义很实际：你不需要修四百个页面，你需要修一个模板。但在那之前，先看那几条示例网址的共同点：是路径上的共同点，还是渲染方式上的共同点。有时候红的是分页页，就是带 ?page= 的那种；有时候是带某个查询参数的结果页；有时候是一个早该退出索引的旧模板残留。
还有个容易忽略的开关：报告默认看移动端。桌面端那栏往往全绿，看着让人安心，但 Google 的索引和评估以移动端为主。我现在的顺序是先看移动端，桌面端只在需要对照时点开。
28 天窗口：今天改的东西，报告今天看不见
这是最消耗耐心的一层。
字段数据是滚动的 28 天。你今天把某个模板的 LCP 从 4 秒压到 2 秒，明天打开报告，看到的还是红，因为窗口里还压着二十多天的旧数据。真正能看到变化的时点，通常要等到两周以后，而且不会一瞬间跳过去，而是慢慢往回挪。
我遇到过这个问题。改完第二天刷一次，没变；第三天再刷，还是没变。于是我开始怀疑改动无效，又去动了别的地方，最后自己也说不清是哪一步起了作用。
现在我改完会做一件事：在笔记本上写日期和改了什么，然后强迫自己两周内不打开那个报告。等两周后再看。如果方向对了，数据会自己说话；如果没动，至少我知道问题不在窗口的滞后上。
还有一点需要接受：报告有流量门槛。访问量太低的源和页面根本进不了 CrUX，也就永远不会出现在报告里。所以「报告全绿」不等于「全站都快」，它只意味着有资格进报告的那部分页面还行。长尾页面、新页面、小语种子目录，这些地方快不快，只能靠实验室数据和自己搭的监控去判断。
LCP 拆成三段，才知道先动哪一段
LCP 是一个由三个环节累加出来的值：TTFB、资源加载、渲染延迟。
TTFB 是服务器响应的时间，包含回源、数据库查询、边缘缓存是否命中。这一段慢，说明问题出在服务端，或者出在缓存策略上，前端图片压得再狠也没用。
资源加载包含两件事：浏览器什么时候才发现这张图，以及下载它花了多久。很多站的问题出在前者。LCP 图藏在 JS 渲染之后，浏览器要等脚本执行完才知道要加载它，那几秒完全是白等。改法通常是让这张图出现在 HTML 里，加 preload，别让它排在队尾。
渲染延迟是浏览器已经拿到资源，却还不能画，被 CSS、同步脚本、字体阻塞住了。
这三段不会在报告里直接告诉你各占多少，但可以在 PSI 的实验室部分和 DevTools 的性能面板里看分解。我判断的顺序是：先看 TTFB 有没有超过 0.8 秒。超过了，先别往下看，去解决服务端；没超过，再看 LCP 元素的发现时机。这个顺序能省掉大量无效优化。
CLS 和 INP：不动主题也能处理的地方
CLS 的来源基本集中在三处，我在几个站上反复见到的都是同样几种：广告位没有预留高度、web font 换字时触发重排、图片没写宽高。
这三处都不需要换主题。广告位给一个固定的容器高度；字体用 font-display 配合预加载，并尽量用系统字体兜底；图片写上 width/height，或者用 aspect-ratio 占位。做完这些，CLS 往往会掉到 0.1 以下，模板一行没动。
INP 是 2024 年 3 月替代 FID 的指标。它量的不只是第一次点击，而是整个访问过程中交互响应的水平。它的主要来源是主线程上的长任务：第三方脚本、埋点、事件处理器里的同步计算。我一般先在实验室里录一段性能，看主线程上那些超过 50 毫秒的块是谁留下的，再决定要把某个脚本延后加载，还是干脆去掉。这一步经常比压缩图片的收益大，但很少有人先做。
我现在怎么读这份报告
打开报告，先看移动端哪个组红，点进去看示例网址的共同点，判断是哪一类模板；再看这一组里 LCP 的三段谁最大；改完记下日期，两周内不刷。
至于排名：字段数据是页面体验的信号之一，并非排名的保证。我见过报告全绿但流量没动静的站，也见过报告黄着但排名稳定的站。把它当成一个需要维护的工程指标，比当成 KPI 去追分数靠谱得多。
