Core Web Vitals 不是考试分,
是订单漏斗。
LCP 四秒意味着第四个访客里就有一个在看你首屏之前走了。这篇把三个指标翻译成「客户在哪一秒关掉页面」,再讲移动优先索引下最容易被忽略的四个坑。
看到一个绿色的小圆圈,很多人就放心了。但三个指标真正在说的是同一件事:客户在第几秒开始不耐烦。把它当考试分数,你会去做「凑分」的动作;把它当漏斗,你会知道先修哪一段。
三个指标,翻译成三句人话
| 指标 | 技术定义 | 客户实际感受到的 |
|---|---|---|
| LCP | 最大内容元素渲染完成的时间 | 「怎么还没出来」——首屏那口饭什么时候上 |
| INP | 交互到下一次绘制的延迟 | 「我点了怎么没反应」——按钮按下去像卡住 |
| CLS | 布局偏移的累计分数 | 「我明明点的是这个」——页面跳了一下,点错了 |
三个指标分别对应三种放弃:还没看到东西就走了、点了没反应就走了、点错了干脆关掉。它们不是三个独立的技术问题,是三个不同的流失点。
LCP:第一印象有多长
“To provide a good user experience, sites should strive to have Largest Contentful Paint of 2.5 seconds or less.” “Based on discussions in the W3C Web Performance Working Group and research done at Google, we've found that a more accurate way to measure when the main content of a page is loaded is to look at when the largest element is rendered.”
第一句给了阈值:2.5 秒以内。第二句解释了为什么用「最大元素」而不是「全部加载完」——因为它更接近人的主观感受。你判断一页「出来了没有」,看的本来也不是所有资源加载完,而是最显眼那块内容出现的那一刻。
web.dev · Largest Contentful Paint (LCP)
外贸站 LCP 超标的头号原因是首屏那张大图。工厂实拍、产品主图、展厅照片,动辄两三千像素、几兆体积,还是原图直传。第二大原因是字体:中文宋体字体文件几百 KB,不加上 font-display: swap 的话,文字会「隐形」到字体下载完才出现——这时候最大元素可能是那张图,也可能是那段文字,反正都没出来。
修的顺序是固定的:图先按显示尺寸重出、换 WebP,首屏图加 preload 或 fetchpriority="high";字体只留必要字重、做成子集、加 swap。这两步做完,多数站能从四五秒降到两秒之内。
INP:按下去那一下
INP 是 2024 年才正式替代旧的首次输入延迟(FID)的,它衡量的是「用户操作到画面更新」的延迟,取的是整次访问里较差的那次交互。也就是说,一个页面访问十次只卡一次,也可能拉低整体分数。
卡的原因几乎都是主线程被占了:页面构建器的初始化脚本、轮播组件、在线客服的 SDK、统计和像素、社交分享按钮。这些东西都在「页面看起来好了」之后才跑,用户一点就撞上。
静态站天然好一些,但也有自己的坑:一次性加载了三个不同来源的第三方脚本,对方一慢,你的主线程就跟着卡。所以对静态站来说,INP 的优化重点不是「代码写得快」,是少放东西。
CLS:那一下跳动
CLS 的成因很具体,就是三件事:图片没写尺寸、广告或横幅后来才插入、字体替换导致重排。
图片没写 width 和 height,浏览器不知道要留多大地方,等图下载完再撑开,下面的内容整体往下跳。这一条是最容易修的:给每个 img 写上真实宽高,或者用 CSS 的 aspect-ratio 固定比例。
CLS 在手机上更严重,因为屏幕窄、内容多,跳一下可能就把用户正要点的按钮换成了另一个。转化页面上这一条尤其致命——他要点「联系我们」,结果点到了旁边的「下载目录」。
这三个指标,各对应哪一种流失?
| 指标差 | 客户会做什么 | 先修什么 |
|---|---|---|
| LCP > 4 秒 | 还没看到内容就返回,连你卖什么都没看到 | 首屏大图 + 字体,这两项通常占八成 |
| INP > 500 毫秒 | 点了没反应,重复点,然后放弃 | 砍第三方脚本,能延后的延后 |
| CLS > 0.25 | 点错按钮,以为站有问题,不再信任 | 给所有图片写宽高,预留广告位空间 |
注意表格第三列的顺序:修的顺序应该按「投入产出比」排,不是按指标严重程度排。图片尺寸这件事,一小时能改完,收益还最大。
移动优先索引:四个容易被忽略的坑
谷歌现在主要用手机版页面来判断你的站。这句话的实际含义比听起来严重:你手机版页面上没有的东西,等于全站都没有。
- 手机版藏了内容。为了「简洁」把参数表、认证列表、案例在手机上折叠或者干脆隐藏,桌面版有、手机版没有。这些内容不会被收录。
- 手机版没有结构化数据。有的模板只在桌面版注入 JSON-LD,手机版漏了。
- 手机版链接更少。手机上删掉了内链区块,爬虫发现的路径就变少了。
- 手机版图更小但更糊。为了省流量把图压到看不清,用户第一眼就判定「这站不专业」。
自查方法:用手机打开你的站,把桌面版和手机版并排放,逐块对比「这块内容还在不在」。少掉的每一块都是白白让出去的收录机会。
看分数,还是看第七十五百分位?
PageSpeed Insights 给两个分数:一个是实验室数据(一台机器跑一次),一个是真实用户数据(来自 Chrome 用户体验报告)。两者打架的时候信后者。
真正要看的是「第 75 百分位」:把过去 28 天所有真实访客的体验排序,看第 75% 那个人拿到什么分数。这个口径意味着——你本地跑出 95 分,但如果四分之一真实用户在四秒以上,你的分数就是「需要改进」。
也意味着别为了凑分做动作。把一个装饰图从首屏挪走,分数立刻好看,但客户的体验没变。分数是结果,不是任务。
实际操作上,先看 Search Console 的移动端报告——它会把问题分成「LCP 慢」「CLS 高」「INP 长」三组,并给出具体的示例 URL。从示例 URL 里挑访问量最大的那个去修,比逐页优化效率高得多。修完再点「验证修复」,谷歌会重新采样,通常要等二十八天才会更新整组数据,别指望第二天就变绿。
改完为什么还会退回去?
静态站在这个指标体系里有两个结构性优势:没有程序要执行,LCP 的服务器那一段几乎是零;没有插件和构建器,INP 少了一大半可能的元凶。
但三件事仍然得人管,而且我们是在出站时就做掉的:图片按显示尺寸生成、字体按页面用字裁子集、每张图都带宽高。这三件事的好处是——它们不会随内容增加而退化。你发十篇文章、加五十张产品图,失控的可能性很小,因为尺寸是构建时算的,不是编辑随手传的。
每次发布带版本号还有一个附带好处:改了资源,浏览器一定拿新的。不会出现「你改了但客户看到旧图」这种既影响体验又难排查的情况。
想知道自己的站卡在哪一段,把网址发我。我按三个指标量一遍,告诉你先修哪一项能把钱捞回来。
资料来源
- web.dev · Web Vitals(三项指标的定义与阈值,第 75 百分位口径)
- web.dev · Largest Contentful Paint (LCP)(为什么用最大元素衡量)
- Google 搜索中心 · Core Web Vitals(Search Console 报告与排名信号说明)
- Google 搜索中心 · 移动优先索引