Google 的排名因素里，大部分是黑盒。Core Web Vitals（核心网页指标）是少数几个有明确阈值、可量化、可验证的部分。

更重要的是：页面性能影响的不只是排名，还直接影响跳出率。一个加载 5 秒的页面，用户在你看到标题之前就走了。

三个指标，各自的及格线

指标	测什么	良好	需要改进	差
LCP	最大内容元素的渲染时间	≤ 2.5s	2.5–4.0s	> 4.0s
INP	点击到界面响应的时间	≤ 200ms	200–500ms	> 500ms
CLS	布局意外偏移程度	≤ 0.1	0.1–0.25	> 0.25

这三个值基于真实用户数据（第 75 百分位），不是实验室跑分。所以要看的不是 PageSpeed Insights 的总分，而是 GSC「核心网页指标」报告里的分组结果——那里才是真实用户量出来的。

LCP：先搞清楚「最大元素」是谁

最常见的错误做法：一上来就去优化图片压缩，结果真正拖慢 LCP 的是网页字体加载。所以第一步是定位元素。

在 PageSpeed Insights 的 LCP 详情里，会直接标出「最大内容元素」是哪个 DOM 节点。内容站的 LCP 元素通常是这三种之一：

• 文章特色图（<img>）
• 首屏大标题（受字体加载影响）
• 整块首屏卡片（受 CSS 阻塞影响）

如果是图片

1. 不要给首屏图片加 loading="lazy"。懒加载会推迟图片请求，是 LCP 变慢的头号原因。首屏第一张图应该用 fetchpriority="high"。
2. 加上 width 和 height 属性，或 CSS aspect-ratio，让浏览器提前预留空间。
3. 换现代格式。AVIF 通常比 JPEG 小 40%–60%，WebP 小 25%–35%。用 <picture> 做兼容降级。
4. 用带宽度参数的 CDN 缩略图，别在移动端加载 2000px 宽的图。

<img
  src="cover-800.avif"
  srcset="cover-400.avif 400w, cover-800.avif 800w, cover-1600.avif 1600w"
  sizes="(max-width: 768px) 100vw, 800px"
  width="1200" height="630"
  fetchpriority="high"
  decoding="async"
  alt="文章配图描述"
>

如果是字体

网页字体是隐藏的 LCP 杀手。默认行为下，浏览器会等字体下载完才渲染文字，这段时间页面是空白的。

两个改法一起用：

@font-face {
  font-family: 'MyFont';
  src: url('font.woff2') format('woff2');
  font-display: swap;   /* 先用系统字体渲染，字体到位后替换 */
  unicode-range: U+4E00-9FFF;  /* 只加载需要的字符范围 */
}

中文字体动辄几 MB，能不加载就不加载。如果只是想要标题好看，可以对标题用系统字体栈，正文完全不引入自定义字体——这是收益最大、成本最低的一步。

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI",
             "PingFang SC", "Microsoft YaHei", sans-serif;

顺带要做的三件事

• 开启 Brotli 或 gzip 压缩：Nginx 里 gzip on; gzip_types text/css application/javascript application/json;
• 延迟非首屏脚本：给统计、客服、广告脚本加 defer 或 async，能挪到页面加载后执行的就挪。
• 预连接关键域名：<link rel="preconnect" href="https://cdn.example.com">

INP：问题几乎总在 JavaScript

INP 衡量的是「用户点了之后，界面多久有反应」。它取代了旧的 FID，区别是 FID 只看第一次交互的延迟，INP 看整个会话里所有交互的表现，因此更难作弊，也更真实。

INP 差的原因通常是：主线程被长任务占住了，用户的点击排在队列后面。

排查方式：Chrome DevTools 的 Performance 面板录制操作，看有没有超过 50ms 的长任务。红色三角标记的就是。

四个实际改法

1. 拆长任务：把一次处理几千条数据的大循环，改成用 setTimeout 或 requestIdleCallback 分批执行。
2. 把重计算挪到 Web Worker：纯计算逻辑（搜索、排序、格式化）放主线程是浪费。
3. 减少第三方脚本：每个统计、客服、广告脚本都在抢主线程。数一数你的页面加载了几个第三方域名，能删就删，能延后就延后。
4. 事件处理用被动监听：滚动和触摸事件加 { passive: true }，避免浏览器等待你的处理函数。

window.addEventListener('scroll', onScroll, { passive: true });

CLS：几乎所有偏移都能提前消灭

CLS 计算的是页面加载过程中，元素发生意外位移的累计程度。典型场景：图片没预留高度，加载完把下方内容全部推下去；或者广告位后插入，把正文顶走。

判断标准：任何会造成位移的元素，都要在它出现前把空间留出来。

四个必改项

• 所有 <img> 和 <iframe> 都要有宽高或 aspect-ratio。这是 CLS 的第一大来源。
• 广告位、推荐位预留固定高度：min-height: 250px; 空着也比撑开好。
• 字体用 font-display: swap 时要注意尺寸差异：如果自定义字体和回退字体的字宽差很多，换字时会产生位移。用 size-adjust 微调。
• 不要用 JS 在首屏顶部动态插入内容。要插入就放在页面加载前，或者放在不会推动已有内容的区域。

.ad-slot { min-height: 250px; contain: layout; }

执行顺序：先把预算花在对的地方

不要平均用力。按下面这个顺序做，收益递减最明显：

优先级	动作	主要改善	成本
1	首屏图片去掉 lazy、加 fetchpriority	LCP	极低
2	所有图片补宽高 / aspect-ratio	CLS	极低
3	去掉中文字体自定义加载	LCP	低
4	开启 gzip / Brotli	LCP	低
5	图片转 WebP / AVIF	LCP	中
6	第三方脚本 defer / 删除	INP、LCP	中
7	拆长任务、上 Worker	INP	高

前四项通常能在一天内完成，而它们能解决大部分站点的绝大多数性能问题。

怎么验证真的改好了

顺序很重要：

1. 改完立刻测实验室数据：Lighthouse 或 PageSpeed Insights，确认指标方向对。
2. 等 28 天看真实用户数据：GSC 的核心网页指标报告按 28 天滚动窗口计算。当天改完就想看到分组变化是不现实的。
3. 对比前后分布：不只看「良好」百分比，还要看「差」的比例是否下降。把「差」清零比把「良好」推到 90% 更有价值。

常见问题

PageSpeed 分数低就一定会被降权吗？

不会。排名用的是真实用户数据（CrUX），不是实验室跑分。Lighthouse 分数受测试环境影响很大，主要用于定位问题，不能直接等同于排名信号。

站点用了 CDN，性能还需要优化吗？

CDN 解决的是网络传输延迟，解决不了图片没压缩、字体拖慢渲染、JS 阻塞主线程这些问题。CDN 是必要条件，不是充分条件。

CLS 只在交互后出现，要管吗？

要。CLS 分为「加载期间」和「加载后」两部分。用户滚动或点击触发的位移也计入指标，所以动态插入内容、展开折叠面板时要预留空间。