A/B 测试的核心 Web 生命力：您的 A/B 测试软件是否会降低您的网站速度？

谷歌刚刚放弃了他们的 Core Web Vitals 更新，我们需要注意它。

为什么关心？

作为 CRO，我们通常不会过多担心流量方面，因为我们关注的是当人们登陆我们的网站时会发生什么以及他们采取的行动。

问题是，此新更新侧重于用户体验，因此它不仅与我们作为优化者相关，而且您的测试实际上可能会对您网站的页面体验分数和流量产生负面影响。

不太好，对吧？

在本文中，我将向您介绍此更新是什么，它是如何工作的，您的测试如何影响它，一些最佳实践不仅可以减少这个新的 SEO 更新的影响，还可以实际提高您的分数并且可能因此而获得更多的自然流量。

我的 A/B 测试工具会减慢我的网站并影响我的核心 Web Vitals 分数吗？

让我们在上面解决这个问题。 只要您遵循测试和 CWV 设置的最佳实践，Convert 应用程序的速度非常快，不会对您的页面体验或核心 Web Vitals 分数产生负面影响。

然而，并非每个站点都遵循最佳实践，在这些情况下，您的 A/B 测试可能会影响您的页面加载速度、首次输入延迟、累积布局偏移或最大内容绘制，具体取决于您的测试和站点设置方式.

好消息？

这些元素中的每一个都很容易修复。 我们将在本指南中介绍所有这些内容，以及如何提高您的基准页面体验和 CWV 分数，并且在测试时不破坏它们。

Core Web Vitals 和 Google 页面体验有什么区别？

它们看起来很复杂，名字也很花哨，但它们基本上可以分解为跟踪用户页面体验中的关键时刻：

• 您的页面加载速度有多快？
• 用户能多快看到页面上的主要元素并理解它的含义？
• 他们多久可以与页面交互？
• 从单击按钮到发生动作，这种交互作用需要多长时间？
• 页面外观如何，是否易于使用？

我们为什么关心？

我们关心，因为谷歌关心，这是他们指出特定排名因素、它如何工作以及如何改进它的非常罕见的事件之一。 发生这种情况时，值得关注，因为这是即将发生的事情的征兆。

为什么 Google 关心用户体验？

简而言之，如果他们推荐的结果提供了糟糕的体验或不正确的结果，那么他们的用户就有可能开始转向他们的竞争对手。

页面体验尚未被视为主要排名因素。 谷歌最近表示，在你和竞争对手之间一切平等的情况下，页面体验更有可能成为决定谁排名更高的决定因素，这仅仅是因为你提供了最好的体验，但这不是唯一的因素。

（精彩的内容、优惠、EAT 和反向链接总是最能发挥作用。）

然而……谷歌似乎正在朝着用户体验成为未来主要搜索排名因素的方向迈出一大步。 他们将整个排名指数结果更改为专注于移动优先体验和结果。

这意味着虽然页面体验是一种以移动为中心的算法，因为它们的整个索引现在都是移动优先的，但这会影响所有网站所有者以及它们在桌面结果中的显示方式。

您可能在桌面上有很多内容，但它是移动版本，而不是桌面版本，这会影响您在结果中的排名。 不仅如此，谷歌还关心页面的加载速度和布局。 他们多次更新并提高了所需内容的标准，设定了加载时间等标准，所有这些都是为了改进移动搜索。

我之前说过，但最好现在对此有所了解并开始实施最佳实践，特别是因为用户体验可以直接影响我们的 CRO 活动，而您的测试工具也可能会影响这些 SEO 结果……

因此，让我们分解这些页面体验指标中的每一个、您当前的结果、每个指标的含义以及您如何满足他们的要求，以及一些要记住的事情，以便您的测试不会对您的分数产生负面影响。

如何衡量您当前的核心 Web Vitals 和页面体验结果

从技术上讲，您可以为此使用 Google Search Console，但我觉得数据可能有点模糊或有限。 （结果被列为“差”、“需要改进”或“好”。）

相反，请前往 Google 的 PageSpeed Insights 工具并在那里查看您的网站。

Insights 工具非常易于使用。 只需输入您要检查的页面的 URL，让它运行，然后查看移动设备和桌面设备的结果。

您的目标是在移动端和桌面端获得 90 分或以上的分数。

显然，这个页面需要工作，因为移动用户可以完全与这个页面交互需要 14.7 秒！

现在，这个页面需要这么长时间才能在移动设备上加载是有原因的。 它大约有 11,000 个字，上面有 30 张左右的图片和 3 个视频。

通过 GIPHY

这是一个大页面！

在本文中，我将继续改进这个销售页面，因为我们处理每个 Core Web Vitals 报告推荐，以便您可以看到其页面速度和得分的差异。

然后，一旦我更新了站点和页面以满足页面体验和核心 Web 生命力，我将展示在此页面上设置 A/B 测试可能会如何影响我的结果。

• 任何红色的东西都需要尽快处理。
• 黄色的任何东西都可以改进。
• 目前绿色的任何东西都符合要求。

有趣的是，Convert Experiences 应用程序仅在后台将我的页面减慢了 107 毫秒，而 Vimeo 应用程序导致了 1,567 毫秒的延迟。

这不是他们的应用程序的错，而是因为我需要解决我的页面和网站的一系列问题，这些问题导致它无法正常运行。

不过，在我改进这些问题之前，我们需要了解它们的含义以及该工具是如何产生这种结果的……

PageSpeed Insights 工具是如何得出这些结果的？

PageSpeed Insights 工具使用 Google 的 Lighthouse 开发测试工具来了解您的页面的执行情况。

Lighthouse 根据您的页面性能应用特定的权重指标来得出此分数。

这些权重基于最重要的用户体验因素，并且通常会随着 Google 添加新功能来跟踪用户体验而发生变化。 （同样，这就是为什么这似乎是今天要关注的重要事情）。

如果我们将这些权重的最新版本与 Lighthouse 的最新版本进行比较，我们可以看到，与之前的版本相比，Cumulative Layout Shift 和 Total Blocking Time 的重要性被赋予了更大的权重。

这是否意味着其他元素突然变得不那么重要了？

一点也不。 事实上，随着更多网站更新并满足标准页面体验要求，它们的权重可能会降低。

似乎现在的重点已经转移到阻止页面在页面加载时更改布局并减少页面响应用户输入所需的时间。

这些都是我们作为测试人员需要考虑的重要事情，因为我们的测试可能会导致页面加载速度变慢，或者当我们测试新的布局设计时布局可能会发生变化。

Lighthouse 工具采用这些权重，然后使用称为实验室和现场数据的东西将它们应用于您的当前页面，以衡量您页面的性能。

什么是实验室和现场数据？

Lab Data 基本上是对特定条件的模拟，以创建控制环境。 阅读本文的大多数用户将使用它来测试和改进他们的页面。

而现场数据是基于该特定页面上的真实用户体验，但它有点缺陷。 您需要该页面的大量实时流量才能获得结果。 不仅如此，这些流量还必须来自 Chrome 用户，他们也选择了 (CrUX) Chrome 用户体验报告，并非每个人都使用或选择加入。

现场数据的用户得分基于该页面上用户体验的第 75 个百分位。

为什么这很重要？ 因为每个用户的体验可能会因他们的设备和互联网速度而异。

如果您的 26% 的观众在连接速度较慢的 iPhone 5 上浏览，那么您的分数可能会下降到 74%，这表明您的页面“需要改进”。

最后，现场数据基于 28 天滚动汇总，因此报告基于以前的结果。 今天的更改将不会在下一个月的结果中反映出来。

如您所见，现场数据与我们所有人都无关。 好消息是，来自 Insights 工具的实验室数据已经足够好，它为我们提供了足够的信息来了解我们的更改和更新如何影响模拟环境，因此我们可以大致了解我们的网站在野外可能会如何表现。

所以现在我们知道了我们在性能最差/最重要的页面上的基线结果，我们可以了解所有这些指标的含义以及如何改进它们。

谷歌的页面体验指标是什么，三大核心Web Vitals指标，我们如何改进它们？

有4 个基本页面体验指标和另外3 个在称为核心 Web Vitals 的特定子集中（最新 Google 更新的焦点）。

这些基本指标中的每一个都很容易实现。 您所需要的只是一个响应式站点，没有狡猾的代码，不在弹出窗口中覆盖该站点，并且通过 HTTPS 运行。

这些只是基本元素。 Lighthouse 在使用实验室数据衡量您的页面体验性能时，还使用了 6 个页面体验指标。

现在虽然有 6 个 Lab 指标需要关注，但它们都是相互关联的。 这意味着一个人的进步通常会看到其他人的进步。

为了帮助简化这一切，谷歌将这些分解为 3 个核心 Web Vitals：

• 最大的内容涂料
• 第一输入延迟，和
• 累积版面偏移

这些是我们需要改进的地方，也是我们的测试可能影响我们排名的地方。

在了解您的测试如何影响这些分数之前，让我们了解一下下面的每一个核心网络生命以及您需要做些什么来改进它们。

1.最大的内容涂料（LCP）

最大内容绘制基于屏幕上最大可见元素的加载速度。 这可能是英雄镜头、背景图片，甚至是标题文本。

该分数旨在复制您的受众开始看到页面上的主要内容并了解页面内容所需的时间。

目前，LCP 占 CWV 分数的 25%。

您的读者能够理解您的页面对于修复很重要，但不仅如此。 您会看到，导致 LCP 缓慢的大多数问题通常是导致页面变慢并导致其他 CWV 问题的根本原因。 这意味着如果您修复了这些 LCP 元素，那么您已经完成了大部分工作。

您的目标应该是让您的 LCP 在 2.5 秒内加载。

降低 LCP 分数/速度的主要问题是：

• 服务器响应时间慢
• 渲染阻塞 JavaScript 和 CSS，导致元素延迟
• 缓慢的资源加载时间
• 客户端渲染慢
• 差/错误地设置图像优化。

如何提高您的 LCP 分数

您可以实施几件事来提高您的 LCP 分数。

在我进行任何推荐的调整之前，您可以在这里查看我的示例销售页面 LCP 分数。

目前，我的 LCP 元素在页面上加载需要 3.4 秒，即使它只是文本的标题，而我的页面在变为交互之前需要 14.7 秒才能加载。

如果我们向下滚动浏览 PageSpeed Insights 工具并查看机会，我可以做很多事情来提高整体页面速度并阻止一些减慢 LCP 速度的事情。

让我们来看看所有这些。

一个。 预加载 LCP 元件

您需要做的第一件事是检查当前页面的实际 LCP 元素是什么，因为它可能因页面而异。

在 PageSpeed 工具的移动视图中，向下滚动页面到诊断部分，然后单击“最大内容绘制”元素，看看会出现什么。

在这个特定页面上，我的 LCP 元素是我的标题。

我可以通过整理页面上的其他内容（例如压缩和缓存）来提高文本的加载速度，但是如果我的 LCP 元素是图像怎么办？

在这种情况下，我想在页面上预加载图像，以便它在页面甚至开始呈现之前就开始加载。

这样，图像会立即开始加载，并且不会因其他代码或请求而减慢速度。

这是一件大事。

标准做法是延迟加载页面上的所有图像，以帮助提高页面速度。 但是，当您对 LCP 图像执行此操作时，它实际上会使其加载速度变慢，从而降低您的 LCP 分数！

（如果您也在 A/B 测试 LCP 元素，这将是一个大问题！）

那么我们该如何解决呢？

我们想编写一些代码来指定这个特定的 LCP 元素应该预加载到一个特定的页面上。

您要添加的脚本是 rel=”preload” 脚本，它看起来像这样：

在这个例子中，我告诉这个特定页面预加载 TRAFFIC-SMALL-HEADER 图像（这是该页面的 LCP 图像元素）。 我还指定了多个维度选项，以便它可以为移动设备和桌面加载响应式图像。

仅此更改将有助于解决影响 LCP 分数的任何加载缓慢的图像。

一些 WordPress 或 Shopify 主题将允许您将自定义代码添加到该特定页面的标题中，而一些插件将允许这样做。 否则，您还可以编辑页面的 header.php 文件并直接添加代码。

我在这里介绍了一些基础知识，但我们将要介绍的大多数修复可能会因您的站点和使用的内容而异。 （如果您没有使用 WordPress 或没有开发人员，请让他们在此处查看 Google 的用于优化 LCP 的开发建议）。

由于我的网站是基于 WordPress 构建的，因此我将使用 WPRocket 插件，因为它将帮助我在一个地方解决 LCP 的大部分问题。

湾。 使用高性能/专用主机

一个超级简单的修复实现。 当您的用户加载您的网页时，它会向您的网络主机发送请求以获取页面信息和存储的文件等。

一些网络托管服务在共享托管平台上运行。 这意味着它们在多个站点之间共享基础架构。 因此，这意味着您共享主机上的其他站点的流量可能会降低您自己站点的性能。

迁移到仅 100% 为您的站点提供的专用托管服务不仅更快，而且更安全，并且可以帮助解决页面加载问题和服务器响应时间。

在这里您可以看到我的站点的初始服务器响应时间为 2.67 秒。

升级到专用主机后，它完全消除了服务器响应延迟，为我节省了 2.67 秒的加载时间，还提高了速度指数和交互时间。

C。 启用缓存并增加缓存长度（如果需要）

缓存允许您通过为用户存储站点内容的保存副本来节省服务器请求，以便在重复访问时快速加载。

这样，如果他们回来并想再次查看内容，加载速度会非常快。

d。 推迟非关键 JS + 删除未使用的 JS

当页面加载时，它会轮流一次加载一个内容（异步），或者减慢速度并尝试一次加载多个内容（同步）。 如果您有一个快速的服务器，或者如果您正在快速加载的第 3 方应用程序（例如 Convert Experiences 应用程序），这还不错。

但是，我们可以通过推迟一些元素（告诉它们在更重要的事情之后加载）或删除不需要在每个页面上加载的元素来帮助提高我们的分数和页面速度。

这通常是 LCP 加载问题的主要原因，因为这些元素会尝试在 LCP 元素之前加载。 （它们也可以影响第一个输入延迟）。

您可以在 WPRocket 中指定要延迟或删除的 JS、应用程序或插件。 （只需确保将转换脚本设置为优先加载而不是延迟）。

这样一来，任何非必要的 JS 都会被删除，其他 JS 会被延迟使用，并且 Convert 脚本可以尽快运行。

边注：

您还可以使用此部分来优先加载任何高于折叠元素的元素，例如滑块或轮播。 只需将代码添加到排除部分，它就会正常加载。

e. 考虑代码缩小

您还可以通过缩小网站上的 JS 和 CSS 代码来加快页面加载时间。 缩小用于在不影响浏览器处理资源的方式的情况下删除不必要或冗余的数据，例如代码注释、空格和格式、删除未使用的代码、使用较短的变量和函数名称等。

许多插件将允许您执行此操作。

只需确保在申请后检查您的页面，因为它有时会导致问题。 （特别是在组合代码时，这就是我在这里没有使用它的原因。理论上它应该可以正常工作，但我过去遇到过问题。）

F。 针对延迟加载和响应性优化图像（只是不是 LCP 图像）

可能会降低页面性能的因素是图像大小和您拥有的图像量。

如果您有一个图片较多的页面，您可以通过延迟加载图片来提高加载速度，以便页面下方的图片仅在查看器向下滚动时才开始显示。

（不过请记住预加载 LCP 映像！）

您还可以通过指定特定的图像尺寸来进一步帮助页面加载。 （有时，您可能会意外上传一个巨大的图像，然后将页面压缩到正确的大小时会减慢页面速度。）

G。 使用图像压缩和响应式大小

您可以通过减小文件大小来加快图像加载速度，然后提供响应大小以适合用户使用的设备。

较小的文件大小意味着它们需要更少的资源来加载用户的设备，同时从他们的角度来看仍然保持高质量。

WPRocket 还集成了一个名为 Imagify 的插件来压缩和提供响应式图像（通过为不同的屏幕尺寸添加多个 scrset 选项）。

H。 尽快建立第 3 方连接

如果您的网站上有可以减慢页面加载速度的内容或脚本，您可以将其设置为尽快开始预加载特定元素，以便它们加载更快。

还记得我的视频之前是如何减慢我的页面的吗？

通过设置第 3 方 DNS 预取请求，我可以加快所有这些视频的加载速度。

一世。 使用 CDN 减少加载时间

CDN 或内容交付网络通过将站点的缓存版本保存在离用户位置更近的服务器上，从而进一步加快站点加载速度。

您可以免费使用 Cloudflare 之类的工具来做到这一点。

j. 使用 Gzip 或 Brotli 压缩来优化文件大小

您还可以使用 Gzip 或 Brotli 等压缩插件进一步加速您的网站，但有些 CDN 会自动执行此操作，因此请先仔细检查您的网站是否已安装。 （Cloudflare 已内置此功能。）

那么进行所有这些更改的影响是什么？

我提高了网站加载速度，将其在移动设备上从 13.5 秒降低到 3.3 秒。 我的 LCP 速度现在是 2.1 秒。

这节省了 10.2 秒！

还不错吧？

还有一些问题需要修复，但随着我们处理其他 2 个 Core Web Vitals 的工作，它们应该会有所改进。

2. 首次输入延迟 (FID)

首次输入延迟是衡量当用户尝试执行某个操作（例如按下按钮或单击链接）时页面响应所需的时间。

FID不良的最常见原因是：

• 第一方脚本执行导致交互就绪延迟。
• 数据获取影响交互准备。
• 第三方脚本执行延迟交互延迟。

首次输入延迟的权重为 CWV 分数的 30%，您的目标是将响应时间降至 100 毫秒或更短。

如何提高您的首次输入延迟分数

我们无法在没有实时用户的情况下测量 FID，因此，我们尝试改善总阻塞时间 (TBT)，因为它们都是连接的。

那么让我们回顾一下我们的页面结果......

当我第一次测量我的页面时，我的 TBT 是 1.5 秒（或 1,560 毫秒）。

由于我改进了 LCP 元素，它下降到 0.2 秒（210 毫秒），而完全交互则需要 3.5 秒。

这是因为我们已经解决了一些减慢总阻塞时间的问题，只需修复一些 LCP 问题，例如代码缩小和延迟或删除 JS。

它已经接近所需的速度范围，但让我们向您展示一些您可以做的其他事情，以防您的分数还没有达到。

一个。 预加载内容和链接

这是 WProcket 内部的一个很酷的功能。 通过预加载 LCP 图像，我们告诉页面尽快开始加载 LCP 图像。

通过预加载链接和站点地图，当用户将鼠标悬停在按钮或链接上时，我们会告诉网站开始在后台预加载内容。

这意味着这些资产甚至在用户请求它们之前就开始加载，从而加快了 FID 并降低了他们点击进入的其他页面的总阻塞时间。

这里的好处是其他页面上的 FID 更快，所以让我们看看更多方法来改进它们加载的第一页。

我们可以做的改善 FID 的主要事情是从我们的站点中删除代码膨胀。

继续并在 GTMetrix 中加载您的页面。

哇，这个分数看起来很神奇，对吧！？

好吧，那是因为这是您的桌面乐谱，而不是您的手机乐谱。 （除非您付费定制设备和位置，否则 GTMetrix 将始终在桌面上显示来自 Chrome 用户的页面加载模拟。）

这很好，因为我们要查看的是瀑布部分，以查看页面加载延迟的区域。

米色的条是我们需要改进的地方，因为在这些地方，另一个代码被阻止加载。

我可以在瀑布图中看到一些旧插件和字体正在减慢页面加载速度，因此我可以返回并预加载这些自定义字体。

在瀑布中打开它们，然后将字体 URL 复制并粘贴到 WProcket。 （我应该早点添加它们，但忘了哇！）

因此，让我们看一下消除进一步阻塞和代码膨胀的几种方法。

湾。 删除插件膨胀

如果您的网站已经有一段时间了，那么很容易开始收集一堆插件并添加不再需要的多余代码。

您可以通过删除未使用的插件或执行相同任务的重复插件来加速您的网站。

你也可以：

• 更新插件以查看它们是否运行得更快。
• 或者寻找可以用更少的代码做同样事情的替代插件。

C。 删除主题代码膨胀

某些主题内置了多余的代码，以提供您可能不需要的设计或样式选项，从而导致页面加载时间更长。

您可以用更轻的主题替换您当前的主题，以满足您的需求，并看到页面速度和加载时间的巨大飞跃。

就个人而言，我使用 Neve 免费主题，因为它干净轻巧，总安装大小仅为 75kb，但您可以使用任何您想要的主题。 （只需搜索“快速加载”或“移动优先”主题。）

d。 消除页面膨胀

另一个可能导致页面膨胀和 CLS 问题的主要问题是页面构建器，主要是因为它们使用过多的代码来表示某些功能。

通过删除 Page Builder 插件、简化页面代码、使用 builder 重新构建它或制作自定义 HTML 页面，您可以看到低得多的 DOM 分数。

那么更改后我的分数是多少？

我还没有删除我的页面构建器，但分数仍然下降到只有 130 毫秒 Total Blocking Time 并且页面在 1.9 秒内加载。

想进一步提高页面速度吗？

您可以使用另一个很棒的插件，名为 Asset Cleanup（这是我们团队在 Convert 中使用的插件）。

它允许您指定在站点的每个页面上加载哪些插件或资产，帮助您从特定页面中删除未使用的插件，以免它们不必要地增加加载时间。

例如，您的站点上可能有一个联系表单插件，但它的代码正在加载到不需要它的页面上。

使用 Asset Cleanup，您可以进入该页面，然后向下滚动并告诉插件不要在该特定页面上加载。

3. 累积版式偏移（CLS）

您是否曾尝试单击网站上的某些内容，然后它会移动并显示广告或横幅？

令人沮丧，对吧？

作为优化者，这对我们来说尤其重要，因为像这样糟糕的用户体验可能会导致用户界面损坏或只是观众不知道该怎么做。

（一些不道德的人实际上会将其构建为黑暗设计以获得特定点击等。尤其是销售广告空间的网站......）

CLS 测量页面上移动了多少元素（也就是它的视觉稳定性），然后对您的网站进行评分。 它的目标是阻止这些网站创造这种糟糕的用户体验，它目前的权重是你 CMV 分数的 15%。

您的目标是获得 0.1 或更低的 CLS 分数。

不过，影响布局变化的不仅仅是广告。 事实上，导致 CLS 评分不佳的最常见原因是：

• 没有尺寸的图像
• 没有尺寸的广告、嵌入和 iframe
• 动态注入的内容，例如侧边栏或标题中推送内容的广告
• Web 字体通过从通用字体更改为自定义字体并影响布局间距而导致 FOIT/FOUT
• 在更新 DOM 之前等待网络响应的操作。

好消息是，我们已经通过修复 LCP 和 FID 的问题解决了很多问题。

• 我们设置了图片、广告和 iframe 视频尺寸。
• 我们已预加载任何自定义字体，因此它们不应导致布局变化。
• 而且，如果您删除了页面构建器，则应该降低页面的整体 DOM 元素，使其更快并减少请求！

如果您向下滚动 PageSpeed Insights 工具并单击“避免大的布局变化”，您可以查看页面的哪些元素当前导致 CLS 问题。

在我的示例中，它只是将标题更改为移动设备的响应式布局，并且不会对 CLS 产生太大影响。

您的站点可能有所不同，因此请查看导致问题的原因并加以解决。

既然我们已经介绍了 Core Web Vitals 的每个领域以及如何改进它们，让我们看看您的测试如何影响您的分数。

Core Web Vitals 如何影响 UX 和 A/B 测试（以及如何在使用转换脚本时通过 Core Web Vitals 评估）

只要您坚持我们迄今为止所涵盖的最佳实践，您就不应该遇到太多问题，但让我们分解它们。

如何在 A/B 测试时不对最大的内容绘制分数产生负面影响

请记住，LCP 元素是在初始页面加载时在取景器或屏幕上看到的，因此您甚至可能没有测试任何 LCP 元素，但以防万一：

如果您正在测试 LCP 元素，例如新背景、主图或标题，该怎么办？

您在这里可能遇到的问题不是转换体验工具，而是 LCP 改进的不良做法。

就像我们前面提到的，大多数人都会犯懒加载所有图像的错误，包括 LCP 图像，这会影响 LCP 分数。

Convert Experiences uses both 'synchronous load' and 'body hide' methods to run tests. Simply put, the tool recognizes the element to be tested and then hides it as soon as it starts to load so the user never sees it, before changing it in under 50 milliseconds.

If you've lazy-loaded that LCP element though, the Convert Experiences app is going to have to wait for that element to load before it can do its job.

You can fix this by preloading the specific LCP elements on your control and test pages like we suggested above. This will get them to start loading immediately on page load, allow them to be recognized and hidden by the Convert app, and be replaced asap before the user notices.

Not only will this reduce flicker, but it will also give a good LCP score as the main LCP element (even when tested) will load fast.

And if the LCP element is not what you're testing? You should be pre-loading it anyway to improve that LCP score.

How to Improve First Input Delay when A/B Testing

The Convert code is incredibly fast, but your FID score still relies on all the other elements of your page.

Make sure to hit all the main requirements for speed that we talked about before so that there is no delay in the Convert code running. (Otherwise, the element you are testing will be hidden until it loads and then changes.)

• You can remove code bloat from other JS and defer them from running.
• You can also 'exclude' the Convert script from being deferred so that it loads up before any other JS so that it can make those test changes asap, while not hurting FID.

If you don't prioritize the Convert code and instead defer it by accident, it may not affect your FID score that much, but it might cause your test element to delay loading, while the script waits to run.

How To Decrease Cumulative Layout Shift Issues When A/B Testing

The potential issues with Cumulative Layout Shift and testing come down to how you run a layout test.

Ideally, you don't want to test massive layout changes with just the Convert Experiences editor. Instead, you want to test similar elements for variations ie swapping out a hero image for another image or swapping text for variations, etc. This means that the page layout stays the same, but a key element is swapped out for a variation.

But what if you want to test a minor layout shift, such as swapping the hero image and text location?

I recommend using Convert Experiences for small layout shifts to set up the test and then see how much it affects your CLS score before you push it live.

A real-world example:

Let's say that I set up that same flipped layout test as above. First, I would build the test inside the Convert Experiences app.

Then I can test this page variant in the page speed tool to get an idea of how it affects CLS.

Make sure you have the variant page open, and then click on the pen icon next to the variant in the Convert Experiences app, then select 'Open Force Variation URL':

This will load a pop up.

Make sure you have the variation page highlighted and then click to copy the URL.

You can input that URL into the PageSpeed Insights tool and measure the CLS and other CWV vitals for that variant.

Full disclosure:

In this particular example, I have not fixed any of the code bloat issues on this other page yet, but here you can see the original control page results based on just the LCP improvements.

速度和 TBT 都很棒，但是 CLS 超出了我们在控制页面上的目标，因为我在我的网站上使用的页面构建器仍然会导致问题。

但是，出于兴趣，让我们将控制页面上的 CLS 分数与变体的结果进行比较：

如您所见，变体页面上的 CLS 可以很好地使用，因为分数仍在指导范围内。

（一旦我使用页面构建器对代码膨胀问题进行排序，速度问题就会得到解决，但转换体验应用程序和布局测试运行速度非常快。）

所以小的布局更改可以工作，只要确保在推送它们之前先测试它们。

但是，如果您想测试较大的布局变化，例如完全重新设计或删除或添加页面元素，该怎么办？

通过 GIPHY

在这种情况下，我将遵循相同的最佳实践来测试动态重新设计或大型布局更改，即运行拆分 URL 测试。

与其使用 Convert WYSIWYG 编辑器来调整和删除所有多余的文本元素，不如在预先完全编辑和构建变体页面的情况下运行拆分 URL 测试会更有效。 （无论 CLS 是什么，这都是最佳实践）。

通过这种方式，您可以测试变体页面与控件并获得两者的快速加载时间，而不会因那些主要的布局变化而影响您的 CLS 分数。

结论 + 要点

所以你有它。 我们的 Google Page Experience 完整指南、3 Core Web Vitals 更新、您的测试如何影响这些 Vitals 以及如何提高您的分数。

想要进一步调整吗？

根据您的特定用例需求，您甚至可以编辑 Convert Experiences 应用程序以异步运行、停止身体隐藏功能，或者甚至使用异步并同时删除身体隐藏功能。 （您可能希望这样做以帮助更快地加载并停止等待工具完成加载的其他资产）。

大多数用户永远不需要这样做，特别是如果您遵循我们迄今为止制定的最佳实践。 （如果您仍在苦苦挣扎，如果您是 Convert Experiences 用户，您可以随时联系我们的支持团队。）

记住：

• Convert Experiences 应用程序非常快，但如果您遵循 Core Web Vitals 和 A/B 测试的最佳实践，它可以更好地工作。
• 谷歌很少提供有关特定排名信号的信息，因此页面体验和核心网络生命力很重要，并且在未来可能会继续变得更加重要。 （自早期版本以来，他们已经提高了站点速度阈值。）
• 根据 Google 的说法，Core Web Vitals 在所有其他条件相同的情况下是决胜局，因此在高端竞争时值得这样做。 如果内容或报价的质量相同，并且竞争页面的页面排名相似，那么用户体验将决定搜索页面排名。
• Core Web Vitals 关注页面上的实际用户体验，因此这对 CRO 很重要。 值得应用最佳实践，因为这会影响页面加载速度、跳出率、点击率、转化率等，尤其是在移动设备上。
• Core Web Vitals 甚至可能开始影响付费流量登陆页面体验以及您在广告拍卖中的表现/投放广告的成本。 改善这一点可能会影响广告成本和投放。
• 您需要具备满足页面体验要求的基本元素。 快速加载、CDN、缓存、HTTPS，在您查看其他要改进的元素之前。
• 代码膨胀和加载顺序会影响首次输入延迟和最大内容绘制。 您需要知道如何设置、限制、预加载元素或延迟 JSS 和 CSS 以有效地加载您的页面。
• 在测试首屏内容（在任何设备的查看区域中）时，请注意 LCP 元素以及预加载它以减少 LCP 问题的必要性——尤其是如果这是您的测试重点。
• Convert Experiences 应用程序运行速度如此之快，不会对 Core Web Vitals 产生负面影响，假设您正在运行 A/B 测试，而大的布局更改不会发生变化。 （将元素替换为相似元素、将文本替换为文本、将图像替换为图像、按钮变体等）。 否则，这将影响 CLS。 （您始终可以在上线之前测试任何布局更改变化。）
• 当执行较大的布局更改时，建议进行拆分 URL 测试（就像动态测试一样），因为这会影响 CLS。 只需确保将获胜的变体更新为原始 URL，并 301 重定向变体可能获得的任何链接（罕见情况）。