Google Analytics 导致核心 Web Vitals 失败：后续步骤

对于想要吸引、参与和转化用户的在线企业主来说，失败的核心网络生命是一个严重的警告。

Google 的 Core Web Vitals 是衡量网站对现实用户的愉悦程度的官方基准，它包含三个性能指标：

• 最大内容绘制 (LCP) 测量初始加载时间
• 与 Next Paint 的交互 (INP) 衡量响应能力
• 累积布局偏移 (CLS) 衡量布局稳定性

这些指标共同提供了一种基于真实用户交互来衡量网站性能的标准化方法。 通过评估表明您的网站加载速度快，反应快，并且在用户与之交互时不会表现异常。

因此，当 Google 自己的 Analytics 似乎导致 Core Web Vitals 评估失败时，我们会感到非常惊讶。

我们来调查一下吧！

谷歌分析如何工作？

Google Analytics 的工作原理是跟踪网站上的用户交互并提供有关用户行为、流量来源和转化的见解。 它是通过添加 Google Analytics 提供的跟踪代码片段在网站上实现的。

此 JavaScript 代码段也称为全局网站代码 (gtag.js)，会进入您要跟踪的每个网页上的网站部分：

此代码收集有关用户交互的数据，例如页面浏览量、点击次数和转化次数，并将其发送到 Google 的服务器进行分析。 然后，网站所有者可以通过 Google Analytics 仪表板访问这些数据，以深入了解其网站的性能和用户参与度。

到目前为止，一切都很好。

现在，让我们看看幕后发生了什么。

对性能的影响（仔细观察）

在禁用缓存和没有主动性能优化的情况下进行仔细检查后，我们发现 gtag.js 作为单个 HTTP 请求加载，重量仅为 111kB，Microsoft Clarity gtag 为 769B。

就初始页面加载而言，Google Analytics（分析）跟踪代码会显示预期的行为，并且不会导致过多的 HTTP 请求、未使用的 JavaScript 或阻塞的主线程。

那么，这种误解从何而来呢？

Google Analytics 真的会影响核心网络生命吗？

仅将 Google Analytics 跟踪添加到您的网站并不会存在未通过 Core Web Vitals 评估（或特别是 Lagest Contentful Paint）的风险。 这只是因为放置在网页头部的代码片段非常轻量级，并且不会阻止渲染页面内容的任何重要过程。

那么，为什么网站所有者将失败的 Core Web Vitals 链接到 Google Analytics？

实验室数据和现场数据之间的差异

我们的经验表明，在阅读 Google PageSpeed 报告时仍然存在相当大的误解。 主要是因为报告随着时间的推移而演变。

让我们澄清一下困惑。

推出 Core Web Vitals 后，Google 团队努力将注意力转移到我们所谓的“现场数据”上——现在显示在报告的最顶部，作为 Core Web Vitals 评估。

它是根据 CrUX 数据集（又名 Chrome 用户体验报告）中与您的网站交互的真实用户的数据生成的。

基于 amazon.com 现场数据的核心网络生命力评估

在 Google 的 Core Web Vitals 成为出色用户体验的标准之前，我们依赖于性能得分（从 0 到 100 进行测量），现在显示在 CWV 评估之后。

基于 amazon.com 实验室数据的性能得分

它被取消优先级的原因是它没有准确地代表用户登陆您的网站时发生的情况。 性能分数是使用 Lighthouse 的“实验室数据”生成的，换句话说，这些是模拟环境的结果。

从上面的屏幕截图中可以看出，亚马逊出色地通过了核心网络生命力测试，但在受控环境中，总阻塞时间 (TBT)、速度指数 (SI) 和 LCP 问题被标记为需要进一步改进。 这是隔离特定问题并对其进行优化的好方法。

然而，归根结底，最重要的是真实用户如何体验您的网站，这就是您应该首先关注的地方。

最终判决

总之，如果您未通过 Core Web Vitals，Google Analytics 跟踪不太可能是原因。 相反，请确保您阅读的不是实验室结果而是现场结果，并为您的 PSI 报告提供另一个卷轴以探索机会和诊断部分。

Google 跟踪代码管理器和 Google AdSense 怎么样？

事实上，网站所有者很少会进行分析并结束工作。

对于想要跟踪特定事件并在其网站上投放广告以从传入流量中获得额外收入的在线企业来说，Google 跟踪代码管理器和 Google AdSense 是流行的工具。

虽然 Google Analytics 本身并不是性能问题的根源，但我们 NitroPack 的工程师始终会进行深入分析，以确定真正的罪魁祸首。

使用我们之前的kiteworks.com示例，我们看到在与主页交互时，来自标签管理器的一系列额外事件标签 (gtm.js) 被触发。

这是很多额外的 gtm.js 标签，因此 HTTP 请求数量过多。

由于 Google Analytics 代码先于其他所有内容加载，因此当您的网站有大量事件标签时，您可以预期 GA 代码段会调用所有其他 gtm.js，从而导致加载延迟和指标结果恶化，例如：

• 最大的内容涂料
• 总阻塞时间
• 首次内容绘制 (FCP)

在您的 PSI 报告中，此类字符串将被标记为“减少未使用的 JavaScript”警告：

如果您的 Google 跟踪代码管理器看起来像这样，那么是时候整理和重新组织了：

修复由 Google 标签管理器导致的“减少未使用的 JavaScript”

第一步是使用async或defer属性延迟第三方脚本，并让它们在后台加载。 这些属性本质上将脚本变成非阻塞并减少第三方代码的整体影响。

虽然相似，但这些属性有重要的区别：

• 具有defer属性的脚本保持其相对顺序。 浏览器不会等待它们呈现页面，而是按顺序执行它们。 例如，我们有两个脚本——脚本 1 和脚本 2——按这个顺序。 如果我们推迟两者，浏览器将始终首先执行脚本 1，即使首先下载了脚本 2。
• 具有async属性的脚本是完全独立的。 哪个先加载就先执行。

Gtm 标签默认是异步加载的，但是当有这么多标签时，就像有两个很长的请求队列一样——即使它们正在传递，但一次只能传递一个，并且不可避免地要等待。

通过首先优化 Google 跟踪代码管理器事件的数量，然后推迟它们，您可以确保初始加载不会遭受不必要的延迟。

使用 NitroPack 减少未使用的 JavaScript 并优化您网站的所有资源 →

Google AdSense 的风险和权衡

当网站所有者在网页上使用各种格式的专用广告单元时，Google AdSense 会为每个广告单元提供代码段 (HTML/JavaScript)，这些代码段将粘贴到应显示广告的网站页面的 HTML 中。

当用户访问包含 AdSense 广告代码的网页时，浏览器会执行 AdSense 提供的 JavaScript 代码，从而为网站所有者带来展示收入。

遗憾的是，由于 AdSense 广告具有阻止呈现的特性，因此可能会影响网站性能（特别是 LCP 和 CLS 等 Web Vitals）。

使用 NitroPack，网站所有者可以选择“优化广告”，这将延迟 JS 直到用户交互。 但由于 AdSense 基于展示次数，这可能会导致一些广告收入损失。

在这种情况下，根据受众的行为，您应该决定什么对您的业务更有利：

1)最佳性能以获得更好的浏览体验

或者

2)产生尽可能多的广告收入，但最终会因不稳定的网站行为而失去流量。

常问问题

自托管 Google Analytics 值得吗？

虽然一些网站所有者考虑使用自托管 Google Analytics 跟踪来实现最佳的核心网络生命周期，但几乎没有必要这样做。 与依赖 Google 的基础设施相比，不要增加复杂性、成本和潜在限制，而是重点优化 Google 跟踪代码管理器事件以满足 Core Web Vitals 标准。