作者
Ira Holubovska
当第一版 Google Tag Manager server-side 发布时,网站页面速度优化是营销人员和网站开发者看到的核心优势之一。之所以能实现这一点,是因为跟踪脚本不再需要硬编码,而是通过 Google Tag Manager 来添加。
在本文中,我们将向您展示将代码从 GTM Web 容器迁移到服务端容器如何影响 GTM PageSpeed,实际数据表现如何,以及根据您的具体设置,哪种方案更为合理。
注意:
如果您同时并行运行浏览器端和服务端跟踪,将不会看到 PageSpeed 的提升。例如,如果您同时使用 Facebook Pixel 和 Conversions API,该像素仍会在用户的浏览器中加载并降低网站速度。这种部分迁移的设置,往往是许多团队在认为自己已经完成迁移后,GTM 依然拖慢网站的最常见原因之一。
早在 2016 年,Google 就指出理想的网站加载时间为 3 秒。 与此同时,移动端页面完全加载平均需要 22 秒。
我们生活在一个人们使用手机频率远高于桌面设备的时代,智能手机占到了所有互联网流量的 50% 以上。 然而,据 Google 统计,移动端手机的转化率低于桌面端。这就是为什么网站加载速度在达到效果标准方面起着至关重要的作用。
众所周知,用户期望获得快速的网站体验。如果着陆页加载过慢,他们会关闭页面或放弃购物车,转而访问竞争对手的网站。 在如今这个移动优先的世界里,构建快速加载的网站至关重要。用户希望能够快速打开任何博客阅读文章、购买新衣服、查看酒店评价等等。
根据 Amazon 的研究,页面响应每延迟 1 秒就会导致转化率下降 1%。对其而言,这相当于每年损失 16 亿美元的营收。
由此可见,让用户等待庞大繁重的页面加载,对任何公司来说都是一笔巨大的成本。
您通过 Google Tag Manager 添加的每个代码都会作为 JavaScript 在用户的浏览器中运行。每个脚本都需要在页面加载之前或之后进行下载、解析和执行,这都需要消耗时间。
并非所有 GTM 设置的表现都相同,这也是大多数困惑的来源。容器的实施方式(Web 还是服务端)决定了 GTM 是增加还是减轻浏览器的负担。在 Web 容器中,您添加的每个代码(分析工具、广告像素、在线聊天小部件、热力图)都是直接在访客浏览器中加载和执行的脚本。
每一个脚本都会争夺相同的有限资源:主线程、带宽和渲染时间。您叠加的代码越多,Google Tag Manager 对性能的负面影响就越会成倍增加,尽管 GTM 本身只是一个轻量级容器。
服务端 GTM 改变了代码执行的位置。服务端容器无需在客户端运行数十个第三方脚本,而是在云端接收数据并将其转发至您的营销和分析平台。浏览器只需与您自己的服务器通信,而无需与十几个不同的第三方网域通信。这就是 Web 与服务端配置之间的 Google Tag Manager PageSpeed 差距通常如此之大的核心原因。
2020 年,Google 为 Google Tag Manager 和 Tag Manager 360 推出了服务端容器。它让广告主能够将第三方代码从自己的网站迁移到托管在云服务器中的全新服务端容器中。通过这种方式,网站加载速度更快,跟踪更加准确,数据也更加安全。将代码移至服务端容器有助于解决此 Google PageSpeed 报错:“减少第三方代码的影响——第三方代码阻止主线程 550 毫秒”。

如果将代码从 Web 容器迁移到服务端容器,代码将直接加载到服务端容器中,而不是在浏览器内部加载。这样一来,页面加载速度会更快,并对用户体验产生积极影响。正如您所见,它可以提供更快的页面加载时间、为客户数据提供更高安全性,并带来更多数据管理工具。 这是服务端 Google Tag Manager 如何在不牺牲跟踪准确性的前提下提升网站性能的最直观范例之一。
服务端容器中的代码只能访问发送到服务器的信息。 它们无法访问用户在网站上输入的其他信息。而且由于这些代码部署在您的服务端容器中,您可以清楚了解哪些代码在收集数据以及这些信息被发送到了何处。
并非所有代码对页面速度的影响都相同,在认定迁移可以解决所有性能问题之前,牢记这一细微差别非常重要。轻量级的分析代码片段和庞大的广告重定向像素所消耗的加载时间大相径庭,尽管它们都“只是一段代码”。占用资源最多的代码往往是那些触发多次网络请求、加载额外脚本或在每次页面加载时运行(而非在特定事件触发时运行)的代码。
亲自验证这一点的最可靠方法,是检查迁移前后的 Google Tag Manager PageSpeed Insights 报告,直接对比结果中的第三方代码部分。
在本次实验中,我使用了一个演示网站,并对比了通过 GTM Web 容器与 GTM 服务端容器添加代码时的 Google PageSpeed 结果。并非所有代码对 Google PageSpeed 的影响都相同。在进行实验时,我决定选择我的客户最常使用的代码以及可以迁移到服务端容器的代码:Facebook、Bing 和 Active Campaign。
GTM 服务端容器拥有适用于 GA4 的原生代码。在这里您可以找到关于如何使用 GTM 服务端容器设置 GA4 跟踪的详细信息。我们还创建了一个自定义模板,帮助您 将 Facebook 像素迁移到服务端环境。
以下是 Google Speed Test 的测试结果。Google 页面速度得分在移动端达到 95 分,桌面端达到 100 分。

我们在服务端容器中安装了以下代码:GA4、Facebook(基础和转化跟踪)、Hubspot 以及 Klaviyo 代码。
当我们将像素移至网页容器时,Google PageSpeed 测试结果下降到了 56 分。


如果您将代码迁移到 Google Tag Manager 服务器端容器,将有效提升网站速度。其影响程度取决于您所使用的代码。在此次测试中,客户中最常用的代码(GA4、Facebook 和 Active Campaign)在迁移到服务端后,都展现出了明显且可衡量的速度改善。
想开始使用服务端跟踪吗?
免费试用
评论