首页 / SEO book / 性能与核心网页指标 / 核心网页指标优化指南

什么是核心网页指标(CWV),还有如何优化它们

核心网页指标优化指南性能与核心网页指标

核心网页指标的数据来自 Chrome 用户体验报告(CrUX),即选择分享数据的 Chrome 用户实测数据。移动端页面体验及其中包含的核心网页指标自 2021 年 5 月起已正式用于页面排名。

核心网页指标(Core Web Vitals)是 Google 用来衡量用户在网页上体验的 3 项指标,分别考察视觉加载速度、视觉稳定性与交互性/响应能力,即最大内容绘制(LCP)、累积布局偏移(CLS)与交互到下次绘制(INP)。FID 已于 2024 年 3 月 12 日被交互到下次绘制(INP)取代。

数据来自 Chrome 用户体验报告(CrUX),其中包含选择分享数据的 Chrome 用户的实测数据。

移动端页面体验及其中包含的核心网页指标自 2021 年 5 月起已正式用于页面排名。桌面端信号也自 2022 年 2 月起被纳入。

Google 的页面体验信号包括 https、无不必要的插页式广告、移动设备友好性和 Core Web Vitals

各项指标的基准如下:

以下更详细地了解每一项核心网页指标,还有如何让页面通过检查。

最大内容绘制(LCP)

最大内容绘制(LCP)是加载视口中单个最大可见元素所花费的时间。它代表网站的视觉加载完成。

Largest Contentful Paint 阈值

这个最大的元素通常是特色图片,也可能是 <h1> 标签。但也可能是以下任意一种:

  • <img> 元素
  • <svg> 元素内的 <image> 元素
  • <video> 元素内的图片
  • 通过 url() 函数加载的背景图片
  • 文本块

<svg> 和 <video> 可能会在未来加入。

如何查看 LCP 元素

在 PageSpeed Insights 中,LCP 元素会在“诊断”(Diagnostics)部分标明。另有一个可选中 LCP 的标签页,只会显示与 LCP 相关的问题。

PageSpeed Insights 中的 Largest Contentful Paint 问题指向蓝色的 LCP 标签页

在 Chrome DevTools 中,按以下步骤操作:

  1. Performance(性能)> 勾选“Screenshots”(屏幕截图)
  2. 点击“Start profiling and reload page”(开始分析并重新加载页面)
  3. LCP 显示在时间轴上
  4. 点击该节点;这就是 LCP 元素
在 Chrome DevTools 中检查 LCP

累积布局偏移(CLS)

累积布局偏移(CLS)衡量页面加载时的视觉稳定性。它通过考察元素的大小与元素移动的距离来实现这一点。

Google 已更新 CLS 的测量方式。过去,即便页面初始加载完成后它仍会继续测量;如今则被限制在布局偏移最集中的五秒时间窗口内。

累计布局偏移阈值

当试图点击页面上的某个元素,页面却发生偏移,结果点到并非想点的东西时,颇为恼人。这种情况经常发生在我身上:点了某个元素,却突然点到广告上,甚至已经离开原网站。作为用户,这很令人沮丧。

尝试点击链接时布局发生偏移的示例

CLS 的常见原因包括:

  • 图片没有设置尺寸。
  • 广告、嵌入内容和 iframe 没有设置尺寸。
  • 用 JavaScript 注入内容。
  • 在加载后期才应用字体或样式。

如何查看 CLS

在 PageSpeed Insights 中,如果选择 CLS,就能看到所有相关问题。这里最需要关注的是“避免大的布局偏移”(Avoid large layout shifts)。

PageSpeed Insights 中的 CLS 问题

我们使用 WebPageTest。在 Filmstrip View(胶片视图)中使用以下选项:

  • Highlight Layout Shifts(高亮布局偏移)
  • Thumbnail Size: Huge(缩略图尺寸:巨大)
  • Thumbnail Interval: 0.1 secs(缩略图间隔:0.1 秒)

注意我们的字体在 5.1 秒到 5.2 秒之间重新应用样式,因应用自定义字体导致布局偏移。

应用自定义字体导致的布局偏移

Smashing Magazine 还使用了一种有趣的方法:用 3px 实线红线勾勒所有元素,并录制页面加载视频,以找出布局偏移的位置。

交互到下次绘制(INP)

交互到下次绘制(INP)衡量网站对用户交互的响应速度。它属于核心网页指标,使用 Event Timing API 的数据来观测页面整个生命周期内所有点击、轻触和键盘交互的延迟。

要达到良好的 INP 评级,INP 需小于或等于 200 毫秒。200 毫秒到 500 毫秒之间的 INP 会被视为一般,低于 500 毫秒则表明响应能力较差。

INP 于 2024 年 3 月取代 FID 成为核心网页指标,它衡量所有用户交互,而不只是第一次交互。

INP 比 FID 更全面,因为它对所有用户交互都敏感,而 FID 仅关注“第一次”交互。

首次输入延迟(FID)

首次输入延迟(FID)是从用户首次与页面交互到页面做出响应之间的时间,衡量的是响应能力。

FID 已于 2024 年 3 月 12 日被交互到下次绘制(INP)取代,不再作为核心网页指标。

交互示例:

  • 点击链接或按钮
  • 在空白输入框中输入文字
  • 选择下拉菜单
  • 点击复选框

滚动或缩放等事件不计入。

想点击某个元素,页面却毫无反应,颇为令人沮丧。

First Input Delay(首次输入延迟)阈值

并非所有用户都会与页面交互,因此页面可能没有 FID 值。实验室测试工具之所以没有该值,是因为它们并不与页面交互。在实验室测试中,你可能需要关注的是总阻塞时间(TBT)。在 PageSpeed Insights 中,可使用 TBT 标签页查看相关问题。

PageSpeed Insights 中的 TBT 问题

延迟是由什么造成的?

JavaScript 争用主线程。主线程只有一个,而 JavaScript 需争相在其上运行任务,可把它想象成 JavaScript 必须排队轮流运行。

长任务阻塞主线程上的处理并导致延迟

当某个任务正在运行时,页面无法响应用户输入,这就是能感受到的延迟。任务越长,用户感受到的延迟越长。任务之间的间隙,就是页面切换去处理用户输入任务并响应其操作的机会。

如何测量核心网页指标

有许多工具可用于测试和监测。一般来说,你想看到的是来自 Chrome 用户体验报告(CrUX)的真实实测数据,因为那才是评估你的依据。这些数据来自选择分享数据的真实 Chrome 用户。该数据集可以通过多种方式获取。

真正重要的数字是页面级别的数字,这些只能通过 API 获得。如果某个页面的数据足够,Google 会使用这些数字;否则,它可能会使用一组相似页面或整个域名的数字来进行评分。其他所有具备页面级数据的工具,都是直接或间接地从这一来源获取数据。

例如,Google Search Console 会拉取这些数据,并向你展示有多少 URL 落在各个区间。

GSC 中 Core Web Vitals 问题的细分

点击其中一个问题,就会看到受影响页面分组的明细。这种页面分组很有道理。大多数用于优化核心网页指标的改动都是针对某个特定页面模板进行的,而该模板会影响许多页面。你在模板中改动一次,该分组内的页面就会一并修复。

存在特定问题的 GSC 页面分组

Ahrefs Site Audit 中的 CWV 报告

用 Site Audit 免费检查 CWV 问题

有许多工具可用于测试和监测。一般来说,你想看到的是真实实测数据,因为那才是评估你的依据,但实验室数据用于测试更实用。

实验室数据与实测数据的区别在于,实测数据考察真实用户、网络状况、设备、缓存等;实验室数据则在相同条件下持续测试,以便测试结果可重复。

许多这类工具都以 Lighthouse 作为其实验室测试的基础。WebPageTest 是个例外,不过也可以用它运行 Lighthouse 测试。实测数据则来自 CrUX。

免费工具:检查多达 10 个页面或网站的桌面端和移动端 CWV 及 Lighthouse 指标

这里还有另一个免费工具,可用它一次性检查多达 10 个页面或网站,看看自己与竞争对手相比如何。

设置:

  • 在指定输入框中填入你的 Google PageSpeed Insights API 密钥。(此处了解如何生成 API 密钥。)
  • 添加你想分析的 URL(每行一个)。

运行分析:

  • 点击 “Check CWV” 按钮开始获取指标。进度指示器会显示请求状态。

查看结果:

  • 结果会以分类整齐的评分卡显示:
  • 每项指标都用颜色标示性能表现:

核心网页指标批量检查工具

以下是一个示例输出,展示速度评分卡的样子。可以把它当作独立工具使用:网站速度测试。

批量页面速度测试工具的输出,显示 CWV 和 Lighthouse 的桌面端与移动端指标

如何优化核心网页指标

要改善整体的核心网页指标,每项指标都需要不同的优化措施。

如何优化 LCP

正如在 PageSpeed Insights 中所见,与 LCP 相关的问题很多,这使 LCP 成为最难优化的指标。我们在最大内容绘制一文中涵盖了更多细节,包括如何修复这些问题。

可用于优化 LCP 的方法包括:

  1. 优先加载资源
  2. 让文件更小
  3. 让文件在地理上更靠近用户
  4. 将资源托管在同一服务器上
  5. 使用缓存

如何优化 CLS

要优化 CLS,需处理与图片、字体,或可能是注入内容相关的问题。我们在累积布局偏移一文中涵盖了更多细节,包括如何修复这些问题。

可用于优化 CLS 的方法包括:

  1. 为图片、视频、iframe 预留空间
  2. 优化字体
  3. 使用不会触发布局变化的动画
  4. 确保你的页面可用于 bfcache(往返缓存)

如何优化 FID

大多数页面都能通过 FID 检查。但若需要处理 FID,我们关于首次输入延迟的文章有更深入的信息,包括如何修复问题。

可用于优化 FID 的方法包括:

  1. 减少 JavaScript 的数量
  2. 尽可能延后加载 JavaScript
  3. 拆分长任务
  4. 使用 Web Worker
  5. 使用预渲染或服务端渲染(SSR)

核心网页指标对 SEO 重要吗?

核心网页指标并不是重要的排名因素。Google 有 200 多个排名因素,其中许多权重并不大。谈到核心网页指标时,Google 的代表曾称它们是微小的排名因素,甚至是打破平局的参考项。我并不指望通过优化核心网页指标能带来多少(如果有的话)排名提升。以下是 Google 的 Gary Illyes 在 2023 年 9 月 Pubcon 大会上关于它们的说法。

尽管如此,它们确实是一个因素,Google 的 John Mueller 的这条推文说明了这种提升可能是如何运作的。

John Mueller 展示 CWV 提升如何发挥作用

多年来一直有速度指标的排名因素。因此移动端页面体验更新推出时,我并不期待能看到多少(如果有的话)影响。不幸的是,页面体验更新期间还发生了几次 Google 核心更新,这让判断影响变得过于混乱,难以得出结论。

有几项研究发现核心网页指标与更好的排名之间存在一定的正相关,但我个人对这些结果持怀疑态度。这就好比说一个注重 SEO 的网站往往排名更好。如果一个网站已经在做核心网页指标优化,它很可能在其他很多方面也做得不错。而且人们确实做了这些优化,正如你在下面这张来自我们数据研究的图表中所看到的。

显示随时间变化的良好 FID、LCP 和 CLS 百分比的图表

核心网页指标的快速事实

事实 1:这些指标分为桌面端和移动端。移动端信号用于移动端排名,桌面端信号用于桌面端排名。

事实 2:数据来自 Chrome 用户体验报告(CrUX),它记录选择加入的 Chrome 用户的数据。这些指标按用户的第 75 百分位进行评估。因此,如果你的用户有 70% 属于“良好”类别,5% 属于“需要改进”类别,那么你的页面仍会被判定为“需要改进”。

事实 3:这些指标是针对每个页面评估的。但如果没有足够的数据,Google 网站站长趋势分析师 John Mueller 表示,可能会使用来自站点各部分或整个站点的信号。在我们的核心网页指标数据研究中,我们考察了超过 4200 万个页面,发现只有 11.4% 的页面有与之关联的指标。

事实 4:在这些新指标加入后,加速移动页面(AMP)不再作为移动端 Top Stories(头条新闻)功能的必需项。由于新报道实际上不会有速度指标数据,很可能使用来自更大范围页面甚至整个域名的指标。

事实 5:单页应用(SPA)在页面切换过程中不会测量 FID 和 LCP 这两项指标。有几项提议的改动,包括 App History API,还有可能改用一项名为“响应能力”的指标来衡量交互性。

事实 6:这些指标可能随时间变化,阈值也可能变化。多年来,Google 已经多次更改其工具中用于衡量速度的指标,还有判断快慢的阈值。

核心网页指标已经发生过变化,而且还有更多针对这些指标的提议改动。如果页面大小(page size)被加入,我一点也不会感到意外。你可以在仍然拥有极大页面的情况下,通过优先处理资源来通过当前指标。在我看来,这是一个较大的疏漏。

结语

我认为核心网页指标对 SEO 没有太大影响,除非你的网站极其缓慢,否则我通常不会优先去修复它们。如果你想为核心网页指标的改进辩护,我认为很难从 SEO 的角度站得住脚。

不过,你可以从用户体验的角度为其辩护。这些改进应该能帮助你在分析工具中记录到更多数据,这“感觉上”像是一种增长。你也可能为更多转化找到理由,因为有很多研究表明了这一点(但也可能是记录到更多数据的结果)。

这里还有一个关键点:与你的开发者合作,他们才是这方面的专家。页面速度可能极其复杂。如果你独自作战,可能需要依靠插件或服务(例如 WP Rocket 或 Autoptimize)来处理。

在新技术的推动下,事情会变得更轻松,许多平台——比如你的 CMS、你的 CDN,甚至你的浏览器——会承担一部分优化工作。我的预测是,几年之内大多数网站甚至都不必太担心,因为大部分优化工作都已经有人处理好了。

许多平台已经在推出或正在研发能帮到你的东西。

WordPress 已经会预加载第一张图片,并正在组建团队专门研究核心网页指标。Cloudflare 已经推出了许多能让你的网站更快的功能,例如 Early Hints、Signed Exchanges 和 HTTP/3。我预计这一趋势会持续下去,直到站长们根本不必再操心这件事。

一如既往,如果你有任何问题,请在 Twitter 上给我留言。