Core Web Vitals

三项指标，各自抓住什么

每项指标负责页面「不对劲」的一种不同方式，而且它们各自独立地失败。有的页面加载很快，却在读者拇指底下滑开；有的页面稳如磐石，却要四秒钟才肯显示点什么。

Largest Contentful Paint 标记的是视口中最大元素渲染完成的那一刻，通常是一张主图或一个标题块。它代表「页面看上去已经到了」，也正因如此胜过首次绘制之类的老标记：一帧空白画得再快，也不是一个加载得快的页面。

Interaction to Next Paint 于 2024 年 3 月取代 First Input Delay 成为稳定的 Core Web Vital，而这次替换是有分量的。FID 只测量首次交互被处理前的延迟，于是抬举了那些第一次点击响应利索、随后就陷进泥里的页面。INP 看的是整次访问中交互的完整延迟，报出的值接近其中最差的那些。

Cumulative Layout Shift 测量的是已经画好之后又移动的内容。这就是那个人人都遇到过的场景背后的指标：伸手去点一个链接，结果按到了刚从底下挤进来的广告。因为它是分数而不是时长，页面靠后的一次严重位移就足以左右整个数字。

以第 75 百分位、用现场数据评判

这一段最容易让团队栽跟头。评判取的是 28 天滚动窗口内页面加载的第 75 百分位，并且移动端与桌面端分开统计。中位数再舒服，只要尾部拖慢，照样不合格——这是有意为之。指标关心的是体验最差的那四分之一访客，而不是那个典型访客。

这也意味着数据来自现场，收集自真实访问，而不是一次实验室运行。实验室工具是诊断仪器：它们告诉你哪个资源卡住了渲染，做这件事它们正是对的工具。但它们不是那份评判，实验室一片绿而现场评判不合格，并不矛盾——那说明你的真实访客不在你测试所用的那台机器上。

真正让每项指标动起来的东西

原因都不光鲜，而且在不同网站之间反复出现。大部分工作是决定浏览器在第一次有意义的绘制之前必须拿到什么，然后拒绝让其他一切挤进那条队列。

第三方脚本值得单独拎出来，因为它既是 INP 问题最常见的原因，又是没人认领的那个原因。每一个为分析、客服、实验或同意管理而加上的标签，都在抢读者那一下点击所需要的同一条主线程。审计时值得问的不是每个标签有没有用，而是它在第 75 百分位上要花多少。

页面体验在信号里的位置

谷歌表示其核心排名系统使用Core Web Vitals，但没有单一的“页面体验信号”。相关性仍然是第一位的，好的 Core Web Vitals 并不能保证排名靠前。

应优先解决用户真实遇到的问题，尤其是重要模板上的问题，而不要把通过阈值视为排名保证。相关性高但体验较差的页面仍可能获得排名；与查询意图不匹配的页面不会因为速度快就变得相关。

一套站得住的工作顺序

如果你是从一份不合格的评判开始的，这个顺序能避开最常见的白费力气：打磨已经通过的部分，或者去修一个没有流量的页面。

1. 先读现场数据，移动端和桌面端分开看。通常只有移动端不合格，修桌面端什么也改变不了。
2. 找出是哪项指标不合格，以及在哪些页面组上。模板是成批一起垮的；单个网址很少能说明什么。
3. 在实验室里、用受限的网络把原因复现出来。实验室告诉你什么慢，现场早已告诉你这件事要紧。
4. 修掉最大的那个单一贡献者，然后发上去。这些指标是靠一次次局部改进挪动的，很少有单一开关。
5. 等满 28 天窗口再下判断。评判是一个滞后的平均值，今天发布的修复会慢慢显现。