• 主页
  • 文章
  • SEO
  • Google 2021 年 5 月更新：深入了解 Core Web Vitals

Google 2021 年 5 月更新：深入了解 Core Web Vitals

已发表: 2021-07-19

更新：数字营销的世界在不断变化，但别担心，我们处于领先地位。 谷歌改变了对即将推出的算法的看法。

在我们的更新中阅读最近的更改，但也可以阅读此博客。

2021 年 5 月，Google 将引入 Core Web Vitals (CWV) 指标，以构成其搜索排名算法的一部分。 这是您需要知道的，并在此之前做……

我们都知道快速网站很重要。 它们创造了更好的用户体验，从而提高了转化率，并且已经将 Google 中的移动搜索排名以及其他页面体验指标（如移动友好性）考虑在内。

但谷歌并没有就此止步。 早在 2020 年 5 月，他们就向我们介绍了 Core Web Vitals，并于 2020 年 11 月 10 日宣布，在 2021 年 5 月，Core Web Vitals 将作为搜索信号纳入整体排名算法。

此外，他们计划“测试一个视觉指示器，该指示器可以突出显示具有出色页面体验的搜索结果中的页面。” 因此，我们不仅通过 CWV 优化获得更高排名的机会，而且我们还有可能提高搜索引擎结果页面的点击率。

立即采取行动来审核和修复这些新的 CWV 指标标记的任何潜在问题，这将使我们的网站有更好的机会在 2021 年此更改生效时获得更高的 Google 排名。

但首先，回顾一下……

回顾：什么是 Core Web Vitals？

Core Web Vitals 是一组包含 3 个新页面体验指标的集合，这些指标会影响整体网站速度得分。 这些指标已经在 Google 的 PageSpeed Insights 工具 PSI 和其他地方的 Lighthouse 性能监控中发挥了重要作用。

新的 CWV 指标包括以下内容： Core Web Vitals 3x 指标

最大的内容绘制 (LCP)

这是折叠元素上方最大元素呈现给用户之前所用的时间。 它占整体速度评分机制的 25%，因此对于将最大的项目在移动设备上的交付时间简化为 2.5 秒或更低至关重要。

许多因素导致高 LCP，包括服务器响应能力、渲染阻塞脚本和样式、CSS 的复杂性、字体和图像

首次输入延迟 (FID)

这衡量了交互性； 页面对用户输入的响应程度如何，例如通过点击或点击。 浏览器响应第一次输入的目标速度应为 100 毫秒或更短。

如果浏览器在页面加载期间解析或执行大量 JavaScript，这将占用 CPU 或阻塞“主线程”，导致设备对输入的响应变慢。 高 FID 通常是 JavaScript 复杂的指标。 这可以是单个脚本或函数或多个脚本。

现有的用于交互时间和总阻塞时间的 PSI 指标与 FID 相关，并且总共占总速度分数的 35%。

累积布局偏移 (CLS)

这是对高于折叠内容的视觉稳定性的度量。 虽然它只占整体速度分数的 5%，但在整体情况下仍然值得考虑。 高 CLS 通常可以指示页面加载期间视觉布局的一个或多个更改，例如当加载横幅时将页面内容向下移动。

速度得分细分

下图显示了总体速度得分的细分以及这些新的 CWV 指标在 GPSI 得分中的作用有多大。

来自 Lighthouse 分数更新的源数据

虽然非 CWV 指标也构成了整体得分，包括首次内容绘制 (FCP)、交互时间 (TTI) 和总阻塞时间 (TBT)，但关注三个 CWV 指标将对其他指标产生直接影响。 例如，如果没有快速 FCP，快速 LCP 是不可能的，而高 FID 分数直接受 TBT 和 TTI 影响。

最大内容绘制优化技巧

LCP 指标由众多个体因素组成，并直接受到高 FCP 的影响。 如果 FCP 被标记为差，您可能需要从这里开始。 网络连接、服务器响应、首字节时间 TTFB 和渲染阻塞文件等任何因素都会影响 FCP 值。 要更深入地了解这些更通用的页面速度建议中的一些，除了下面的 LCP 特定提示外，请查看我们关于该主题的页面速度电子书。

如果 LCP 值远高于 FCP，那么我们需要看看如何更好地简化这个最大元素的显示。

确定最大元素

您可能想要做的第一件事是确定最大的元素是什么。 最大的元素基于像素区域，它可以在不同的断点处发生变化，因此视觉扫描不一定能识别正确的元素。

在 PSI 中，诊断部分应该有一个“最大的内容绘制元素”面板。 或者，您可以通过将鼠标悬停在 Chrome 性能监控工具中的指示器上来查看 LCP，如下所示。 LCP 最大元素诊断

在上例中的 Hallam 站点上，性能监视器将 LCP 显示为主要的“Thrive Online”标题。 理想情况下，LCP 应立即遵循 FCP，如本例所示，如果两者之间存在差距，我们需要尝试了解原因。

字体优化了吗？

如果折叠元素上方最大的是排版，那么我们需要确保字体交付尽可能精简。 这包括：

  1. 使用 CSS 字体显示：swap; 以确保在加载字体文件时立即显示字体。 Google Fonts 和 Adob​​e 的 Typekit 都可以设置字体“显示”参数。
  2. 尝试在服务器上本地托管 .woff 和 .woff2 字体文件，而不是向第三方字体发出跨域请求。 Google Fonts 相当快，Typekit 字体较慢，某些第三方字体代工厂的可靠性较低。
  3. 预加载字体文件会有所帮助。 本地托管的字体通常包含在网站的主样式表中，但必须先下载并解析此样式表，然后才能对其中的字体发出额外请求。 预加载告诉浏览器更快地开始下载字体，而不用等待 CSS 被解析。
  4. 对第三方字体代工厂使用 preconnect 和 dns-prefetch。 这些指令将有助于在对字体发出请求之前在第三方域之间建立 DNS、TLS 和 TCP 连接。
  5. 仅包含折叠显示上方所需的排版字体文件。 Font Awesome 等图标库的字体资产是出了名的繁重，但对这些（以及相应的图标库 CSS）的请求通常可以在 <head> 元素之后延迟和加载。
  6. 不要对主站点样式表中的字体文件发出跨域请求，因为这依赖于连接性和对第三方域的额外查找。
  7. 考虑网络安全字体。 这些不需要对字体文件的任何请求，尽管在美学方面可能非常有限。

图片优化了吗？

通常，折叠元素上方最大的图像将是确保图像优化的重要图像。 以下是一般的良好做法，但对于 LCP 元素尤其重要。

  1. 使用正确的图像文件类型。 JPG 图像应该用于照片，SVG 用于矢量图形和图标，或者 PNG 用于更复杂的非照片图像，如果需要透明度。
  2. 确保以 50-60% 的质量保存或输出 JPG 图像。 在这个水平上，应该没有明显的质量损失。 此外，请确保图像已从中剥离元数据。
  3. tinypng.com 等压缩插件或服务可以自动批量优化图像并去除不必要的元数据。
  4. 图像的大小应适合它们显示的区域。不要在移动设备上输出高质量的桌面图像。
  5. 图像应使用标准 <img> 标签和响应式图像的 'srcset' 属性输出。
  6. 折叠下方或屏幕外图像应使用 loading=”lazy” 属性。
  7. 使用下一代 .web 图像文件格式以获得更高的压缩率。 这可以轻松节省 30%，在许多情况下甚至更高。
  8. 考虑预加载最大的首屏图像，以便在其他可能不太重要的内容之前更快地启动下载。

减少渲染阻塞文件

<head></head> 元素中加载的任何 JavaScript 或 CSS 文件都被视为阻塞渲染，因为需要在页面开始渲染之前下载这些文件。 这会对 FCP 和 LCP 指标产生巨大影响。 仅当它们对页面上首屏折叠显示至关重要时，才应使用头部中的渲染阻塞文件。

删除 <head> 中任何未使用的文件，在页脚中加载非关键文件，或将多个文件合并到更少的文件中，将减少渲染阻塞资产的数量。

不要使用 JavaScript 来显示 LCP

在 CWV 之前，这没什么大不了的。 JavaScript 通常用于动画或显示在折叠元素上方，例如淡入淡出的文本或英雄轮播，通常对速度得分几乎没有影响。

如果最大元素的显示依赖于 JavaScript，这通常会导致很长的延迟，因为必须在元素出现之前下载、解析和执行 JavaScript。 JavaScript 文件通常（并且非常正确）在 <head> 元素之后加载，因此它们不会“阻止渲染”，但这意味着它们仍然可以有效地阻止 LCP 的渲染。

看看下面的例子（标志模糊和标题改变）这是来自 PSI 中一个高分网站。 LCP（主标题文本）与 FCP 相距几秒钟，这是由于 JavaScript（由黄色带表示）在文本淡入之前下载、解析和执行的要求造成的。

文本本身的褪色也可能是一个问题，导致最大元素的延迟显示。

像这样的 JavaScript 技术可以立即将整体速度得分降低 25%，并且不应以任何方式用于阻碍或阻止最大元素的加载。

在窗口加载时执行脚本

JavaScript 很少需要（也不应该被要求）来显示重要的首屏内容，但我们看到的一个常见问题是，一旦 DOM 准备好就可以触发函数。 在流行的 jQuery 框架中，这是通过 'ready' 事件完成的。 Google Tag Manager 还可以在就绪时触发功能或“标签”。

考虑在加载主页面内容后触发窗口加载事件上的关键内容显示不需要的所有 JavaScript，以防止对折叠内容和 LCP 元素的渲染产生任何潜在干扰。

切换 LCP

无论图像如何优化和简化，与排版元素相比，下载和显示几乎总是需要更长的时间。 尽管完全有可能为图像获得快速的 LCP 分数，但有时调整以减少最大的图像元素使其小于最大的文本元素将意味着文本可以用于 LCP。

如果设计允许，这会对分数产生很大的影响，如下面的示例所示，其中 LCP 已切换到文本元素。 LCP开关元件

首次输入延迟优化技巧

正如我们之前提到的，FID 衡量页面对用户输入的响应程度。 它结合了 Time To Interactive TTI 和 Total Blocking Time TBT，可占总速度分数的 35%。

这些指标主要受加载页面时解析和执行的脚本的影响； 阻塞 CPU 的主线程并可能影响设备响应能力，尤其是对于低端智能手机设备。

请务必注意，PSI 中显示的“实验室数据”不直接测量 FID。 这是由于难以模拟的用户点击或点击测量的交互性。 相反，它是由“现场数据”收集的； 基于 Chrome 用户体验报告 CrUX 在 28 天内从实际用户收集的测量结果。

因此，直接针对 FID 进行优化有点困难，因为我们无法更改某些内容并等待 28 天以收集更多数据。 因此，我们应该为此使用实验室数据中的 TTI 和 TBT 指标，因为这些指标的低时间将与低 FID 相关。

那么我们如何针对这些指标进行优化呢？

审核您的 JavaScript

JavaScript 可以有各种形状和大小，单个视频嵌入、聊天小部件、ReCaptcha 脚本或 HubSpot 集成成为高 FID、TTI 和 TBT 指标背后的唯一原因并不少见。

Page Speed Insights 中的诊断面板是一个很好的起点。 “最小化主线程工作”部分将告诉您 JavaScript 占用了多少执行时间，“减少 JavaScript 执行时间”部分将指示哪些文件具有较高的解析和执行时间以及“减少第三方的影响”代码”将突出显示和分组具有高影响力的第三方脚本。

下面的屏幕截图显示了一个站点，该站点具有多个繁重的脚本，交互时间指标为 15 秒。 许多脚本来自第三方，包括 HubSpot 和 Vimeo。

第三方脚本对 Google PageSpeed Insights 的影响

为了更深入地分析和可视化这些脚本如何影响页面加载，Chrome 的性能监视器工具可以是深入了解触发哪些脚本和函数、这些脚本的相对影响以及页面加载这些脚本的位置的好方法正在执行冗长的脚本。

下面的示例来自同一站点，显示由黄色、粉红色和橙色条表示的 JavaScript，较长的条显示执行时间较长的任务。 当我们点击这些较长的任务时，我们可以看到突出显示的脚本与上面 PSI 突出显示的大脚本相关。

性能监视器示例
屏幕截图显示了性能监视器中的大量 JavaScript

一旦我们更好地了解哪些脚本会影响性能，我们可以使用多种技术来最大限度地减少它们的影响，如下所述。

异步加载脚本

JavaScript 默认会按顺序执行。 如果有任何脚本不依赖于其他脚本的加载，则这些脚本应该使用 'async' 属性加载，这样它们就不会阻止其他脚本的解析和执行。

有条件地加载 JavaScript

我们在许多网站上看到的一个常见问题是，大量脚本在不需要时在全局或页面上加载。 例如，如果您需要使用 ReCaptcha 来帮助阻止表单提交中的垃圾邮件，请确保仅在具有表单的页面上加载脚本。

简化 JavaScript 包

JavaScript 库（例如 jQuery UI 或 Bootstrap）通常用于提供额外的 JavaScript 特性和功能。 如果使用捆绑包，请确保只在捆绑包中包含相关功能，以避免下载和解析不必要的 JavaScript。

需要时延迟加载脚本

即使 JavaScript 只加载到需要它的页面上，脚本本身也不一定需要在页面加载或窗口加载事件期间解析和执行。 仅在实际需要时才加载 JavaScript 会对 TTI、TBT 和 FID 指标产生巨大影响。 这里有些例子：

  1. YouTube 和 Vimeo 等视频嵌入通常具有很高的影响力。 请考虑仅在单击视频缩略图时加载这些脚本。
  2. 第三方表单集成（例如 HubSpot）可能是密集型的。 如果表单出现在模式中或页面底部，请考虑在滚动或模式激活而不是页面加载时加载或注入所需的脚本。
  3. 实时聊天小部件可以将整体速度得分影响高达 35%。 考虑将实时聊天小部件移动到支持全局“实时聊天”CTA 的专用联系页面，或仅在单击“与我们聊天”按钮时才注入实时聊天脚本。
  4. 在基于 iFrame 的嵌入式内容上添加 'loading="lazy" 属性会有所帮助，但这是一项新的浏览器功能，需要根据所使用的 iFrame 嵌入进行测试。

评估商业智能工具

使用 Hotjar 等工具或 VWO 等 A/B 测试软件分析用户行为对于商业智能非常重要，在许多情况下，它们的好处将超过对网站速度的影响。

话虽如此，仍然值得根据分析数据的频率来评估 24/7 全天候运行这些工具的重要性。 例如，如果没有活动测试正在运行，则应关闭 A/B 测试，并且在收集和处理足够的数据后可能会停用 Hotjar 等行为分析工具。

累积布局移位优化的技巧

累积布局偏移 (CLS) 可能仅占整体速度得分的 5%，但仍然是整体图片的重要组成部分，尤其是页面加载时大量的切换元素可能会给用户带来不和谐的体验。

确定 CLS 元素

有时可能会很明显是什么元素或元素导致内容发生变化，但始终值得通过 PSI 中的 Layout Shift 面板验证这一点，如下所示。

布局偏移诊断

CLS 指标应低于 0.1，但在上面的示例中，超过了 400%，分数将下降 5%。 如果这是一个全球性问题，那么每页 5%。

应该按照影响的顺序确定和处理变化的元素，并且可能包括折叠上方和下方的元素。 我们在下面重点介绍了布局转换的一些最常见原因和解决方法。

注意动画

使用某些动画技术来改变向用户呈现内容的方式是很常见的，例如，当用户向下滚动页面时，图像、文本或内容面板的淡入淡出或滑动。 虽然这些可能在美学上令人愉悦（取决于您问谁），但这些技术在页面加载期间不会移动任何内容是很重要的。

如果您必须对用户隐藏然后淡入淡出内容，请确保容器大小或总页面高度不会随着内容加载而改变。可以使用 CSS 可见性规则隐藏内容（如有必要）而不是 display: none; 这将保留它所需的基本空间量。

指定图像尺寸

如果 <img> 标签没有设置 width 和 height 属性，或者没有使用 CSS 来设置图像的尺寸或比例，浏览器需要先下载图像，然后才能确定它需要的像素区域显示。这可能会导致在图像加载时呈现在图像下方的任何内容发生偏移。

在下载图像之前在 CSS 中指定图像的宽度和高度，或设置图像（或父容器）的尺寸或比例将确保浏览器知道图像需要显示的区域并避免潜在的布局转移。

横幅

广告、cookie 法条或用于在横幅中显示重要信息的任何其他信息可能是高 CLS 的最常见原因之一。

横幅内容从外部数据源加载或通过 JavaScript 从同一站点加载是很常见的，这意味着在加载内容之前可能无法计算横幅容器的大小。 发生这种情况时，一旦横幅内容加载并显示给用户，横幅下方的内容将向下移动。

对此有许多决议：

  1. 在 CSS 中为横幅或横幅容器设置最小高度，以便浏览器可以有效地呈现占位符。 尽管如果内容量是动态的且未知的，这可能会出现问题。
  2. 绝对或固定横幅在屏幕顶部或底部的位置。 对于可以关闭或关闭的横幅，这是一个很好的考虑，因为固定元素不会影响任何其他元素的定位。
  3. 如果可能，查看横幅内容的服务器端呈现，这意味着内容和横幅尺寸可以在到达用户之前预先加载。

概括

希望您会发现上面突出显示的一些技术在诊断和排除 Google 新 Core Web Vitals 的性能问题方面很有用。 在过去的几个月里，我们在 Hallam 的速度审核和开发团队的直接改进方面帮助了许多客户提高了他们网站的性能。

如果您发现这篇文章有帮助，您可能还想查看我们的网站性能电子书，该书深入探讨了一些关于页面速度的更通用的建议，任何构建或管理网站的人都可以从中受益。