Google跟踪代码管理器对营销人员的主要卖点之一（您甚至可以在其目标网页上注意到）是 它优化了页面速度 要么 页面可以更快地加载。 但这是真的吗？ GTM（或任何其他标签管理解决方案）是否真的为您的网站锦上添花？
简短的答案是： 这取决于.
偶尔，我会注意到论坛线程和在线聊天，人们（通常是数字营销人员）从其IT部门那里收到投诉（GTM降低了网站速度），他们正在寻找有关提高页面速度的技巧。
虽然我了解如何在您的网站上运行GTM的主要最佳做法，但我意识到，我对GTM与页面性能的了解仍然存在一些差距。
什么啊 究竟 和 怎么样 GTM（和各种标签）会影响页面速度吗？这个问题困扰了我很长时间，最近，我决定使用各种GTM设置运行一堆测试，以亲自体验这种效果。
特别感谢 西莫·阿哈瓦（Simo Ahava）。在撰写此博客文章（并收集数据）时，我与他联系是因为对本文存在一些疑问（以及我是否没有遗漏任何东西）。和往常一样，他乐于提供一些技巧和想法。其中一些是 哈！ 在我眼中，其他人提出了更多问题，需要进一步调查。
但最后，我’我对我从漫长的研究过程中获得的新知识感到非常满意。希望你’也会找到有用的东西。
免责声明
您应该阅读本指南，并带着一丁点盐了解我的发现。不要接受一切作为绝对真理。在页面速度和网站性能方面，有许多细微之处会影响结果，但我并未涵盖所有内容。实际上，我认为我只是在抓挠表面。
不过，对于完全不了解页面速度优化并且刚刚起步的人来说，我的发现可能是一个很好的起点和参考。
赶时间的人的简要摘要（TL; DR）
This guide is a lengthy one. 如果你 have time, I definitely recommend reading it from start to finish.
如果你 only have a couple more minutes, then 这里’您应该知道的是：
- 甚至异步标签也会影响网站’s loading speed.
- 空的GTM容器对页面速度的影响最小。最大的违规者可以是您添加到该容器的标签。但是每个标签都不同，影响也可能不同。因此，最终结果是 “It depends”.
- 我在某些测试中使用的8个跟踪标签在将代码硬编码到<head>与通过GTM实施的8个代码相比。但这并非在每种情况下都绝对正确。
- 您的fire标签越晚，它们所产生的负面影响就越小（除非您在单页应用程序中加载了一堆自定义HTML标签。然后，即使在初始页面加载后也能感受到这种影响。 注意：在本指南中，我仅关注初始页面加载。）
- 注意DOM操作。他们需要浏览器资源，在我的一项实验中，他们将浏览器资源增加了3秒 互动时间 指标。
- 服务器端跟踪（GTM将在何时发布）绝对可以提高页面性能。希望此功能将在今年晚些时候发布。
- 启用GTM预览和调试模式时，您不应该测量页面速度（因为它会给访问者带来浏览器无法承受的额外负担）。
- 删除容器中不必要（或不相关）的项目。这将使您与标记管理器的工作更加轻松，并有可能提高页面速度（尽管’t always the case).
如果你有更多时间，那就让’s dive deeper 和 I’ll show you what I’ve learned.
目录
- 第1部分。我的测试如何进行？
- 第2部分。结果与见解
- 第3部分。有关如何最大限度地减少Google跟踪代码管理器的提示’对页面速度的影响
- 最后的话
第1部分。我的测试如何进行？
让’首先说明我的方法和设置。’不必担心设置，请跳至 本博客文章的第2章我在哪里查看我的发现。
设置
为了测量页面速度计时，我使用了 webpagetest.org以及Chrome中内置的网站速度审核工具Lighthouse’的开发者控制台（打开开发工具后，转到 审核 标签）。
在webpagetest.org中，我正在使用：
- 爱尔兰（EC2，Chrome，Firefox）作为测试位置（针对台式机），Oneplus 5设备（针对移动设备测试）
- 3G快速和3G慢速连接
- 每次运行中都有3个测试
- 其他设置为默认设置
在Lighthouse中，我同时使用了移动报告和桌面报告（因为’t many settings).
为了隔离Chrome扩展程序对测试结果的可能影响，我将其用作 来宾。 这意味着不存在浏览器扩展。笔记本电脑’的性能设置为最高。
指标
为了衡量影响，我检查了以下指标。
Webpagetest.org：
- 文件完成 (in seconds). 它显示何时加载了网站静态内容（如图像）。这通常在所有图像加载后发生，但可能不包括由javascript执行触发的内容。完全加载所花费的时间越长，效果越差。
- 完全读取 (in seconds)这是onLoad之后网络活动停止2秒钟的时间（通常，此处的任何活动都是来自页面上的javascript进行的动态操作。完全加载所花费的时间越长，效果越差。
灯塔 （铬’的内置网站审核工具）：
- 第一次有意义的绘画（以秒为单位）。 它测量的是用户启动页面加载到页面呈现首屏内容之间的时间（以秒为单位）（学到更多）。完全加载所需的时间越长，效果越差。
- 互动时间 (in seconds)。它衡量页面完全互动所花费的时间（学到更多）。在以下情况下，页面被认为是完全交互式的：
- 该页面显示有用的内容
- 页面在50毫秒内响应用户交互
- 第一个CPU空闲（以秒为单位）。它测量页面变成多长时间 最少 交互式（当屏幕上的大多数UI元素在合理的时间内响应用户输入）。 学到更多.
- 最大潜在首次输入延迟（FID）（以毫秒为单位）。它衡量的是从用户首次与您的网站进行交互（即当他们单击链接时）到浏览器实际能够对该交互做出响应的潜在时间。例如，如果浏览器仅在1秒钟后对您的点击做出反应，则FID’s value is 1000. 学到更多.
追踪代码
以下是我在某些实验中使用的跟踪代码：
- Google Analytics（分析）综合浏览量代码（gtag.js）
- Facebook像素主代码（跟踪页面浏览量）
- Reddit Pixel转换标签
- Quora像素（跟踪页面浏览量）
- LinkedIn见解标签
- Twitter通用标签（跟踪页面视图）
- Google Ads再营销标签（gtag.js）
- Hotjar主要跟踪代码
我运行了哪种测试？
这是我运行的所有测试的列表。在以下情况下，我使用上述两个工具测量了页面速度：
- 该页面有 没有第三方跟踪代码 和 没有标签管理解决方案
- 该页面有 硬编码的第三方跟踪代码 （闭幕前<head> tag) 和 没有标签管理解决方案. “Hardcoded”表示标记已直接添加到网站’s source code.
- 该页面有一个 空的GTM容器 （和 没有硬编码标签)
- 所有8个跟踪代码都是通过GTM实施的， 所有页面 trigger （又名 gtm.js)
- 所有代码都是通过GTM实现的，启用后 DOM准备就绪 trigger （又名 gtm.dom)
- 所有代码都是通过GTM实现的，启用后 视窗已载入 trigger （又名 gtm.load)
- 所有代码都是通过GTM实现的， 1.5 seconds after the 视窗已载入 触发（此自定义解决方案的想法是从 帕维尔·布雷西克（Pavel Brecik）)
- 在启用预览和调试模式的情况下调试整个GTM容器（稍后我将解释为什么这样做）。此外，我将结果与类似设置（但P&D mode disabled.
- 具有以下内容的GTM容器 100个自定义HTML标签 （都使用相同的简单脚本）。跟踪标签已从容器中移除。没有进一步的测试包含跟踪标记。
<script> console.log('hello'); </script> - 具有以下内容的GTM容器 100个自定义HTML标签 (all use the same simple script that also adds additional elements to the bottom of the page 身体).
<script> console.log('Hello!'); </script> <div> <span>Hello!</span> </div> - 具有以下内容的GTM容器 200个自定义HTML标签 （都使用与先前实验相同的简单脚本）。
- 具有以下内容的GTM容器 100个自定义HTML标签 在标题2之后插入元素的代码。每个标记都包含此脚本（从 这里）：
<script> (function() { var h3 = document.createElement('h3'); h3.innerText = "An additional element"; var title= document.querySelector('h2'); if (title) { title.parentElement.insertBefore(h3, title.nextSibling); } })(); </script> - 具有以下内容的GTM容器 100个自定义HTML标签 在页面的第21个链接之后插入元素的代码。这要求浏览器遍历页面上的更多元素，因此需要更多资源。每个标签都包含以下脚本：
<script> (function() { var h3 = document.createElement('h3'); h3.innerText = "An additional element"; var element = document.querySelectorAll('a')[20]; if (element) { element.parentElement.insertBefore(h3, element.nextSibling); } })(); </script> - 完整的GTM容器Â 具有静态内容 （这意味着它已达到其最大容量（200kb）的100％）。但是我只想解决它的大小并隔离浏览器的一些潜在的昂贵任务，因此，我创建了一个仅包含常量变量的容器（每个容器包含〜1000个字符）。好奇单个GTM容器中可以容纳多少这样的变量？以我为例，这个数字是1976。
我至少进行了3次测试，然后计算出平均时间。
我的意思是说“Page Speed”
每次我提到 页面速度 在此博客文章中，我将重点放在与初始页面加载相关的页面性能上，而不是在此之后发生的事情。但是不要’认为加载所有资源后对性能没有影响。
恰恰相反。当GTM可以将其他节点添加到页面文档中从而需要额外的计算机资源来处理所有内容时，这对于单页应用程序尤其重要。
Simo在多个博客文章中提到了此问题，例如， 这个 和 这个.
第2部分：结果和见解
如果你 want to check more detailed timing data of each experiment, you can 检查此电子表格。这是我要指出的一些关键要点。它们中的大多数是由您交付给您的 上尉船长 （而其他人可能会教您一些新知识）。
异步并不意味着对页面速度没有影响
首先，让’迅速熟悉同步和异步脚本。同步脚本意味着在加载同步脚本之前，浏览器不会加载网站的其他资源（例如图片等）。这会极大地影响网站的性能和用户体验。
想象一下，在页面上有一堆同步脚本会阻塞页面渲染15秒钟，而您看到的只是白屏。
另一方面，异步脚本与其他网页组件同时加载。这意味着在加载脚本时，主页内容也将加载，而’t blocked.
听起来很棒。您可以在没有任何影响网站的情况下加载跟踪代码’的图像和内容加载，对不对？好吧，不是真的。
即使未直接阻止元素，异步脚本仍需要计算机资源，这意味着网站的执行’的主要文件/脚本速度变慢。
几个例子可以证明这一点：
- 网站’s 已载入文件 没有实施任何代码的情况下，事件在4秒内发生了 此表)
- 将一堆标签添加到广告系列后，该数字增加到7.7秒<head> (Cell B7)
“Document complete”事件计时（以秒为单位）。No tags vs 8 hardcoded tags (in website’s <head>)
即使添加一个空的Google跟踪代码管理器容器，网页加载时间（单元格B6-E6）也会稍微增加约0.1秒。
It’s not GTM itself, it’是你放在里面的东西
在我的实验中（并且我进行了多次相同的测试），一个空的GTM容器添加到网站上造成的延迟非常小，约100毫秒（有时甚至没有可见的延迟）。那’s，因为您只是在页面上添加了一个脚本。
对网站的影响’当您向容器中添加其他项目时，页面速度开始。但是，所有项目都不相等。这实际上取决于这些项目（例如标签或变量）的作用。例如，当我向容器添加8个跟踪标签时，在Fast 3G（Cells B8-C8）上，页面速度降低了约3秒，而在慢速3G（Cells D8-E8）上，页面速度降低了约10秒。
“Document complete”事件计时（以秒为单位）。No tags vs 8 tracking tags in GTM
但是，如果您认为仅通过向容器中添加几个项目，该站点就总是会大大减慢速度，事实并非如此。在另一个实验中，我只有1976个常量变量（然后容器达到200kb的大小限制），页面加载时间仅增加了0.1-0.3秒（单元B17-E17）。
这些变量没有调用复杂的功能，没有加载脚本或添加/操作网站元素，因此，其影响不像8个标记（GA，FB Pixel，Twitter标记等）那样明显。
“等一下“，您可能在想，“仅8个标签会使网站速度下降了多少？我以为GTM应该可以优化页面加载速度“. 继续阅读。
硬编码标签（在<head>放慢网站速度（与GTM和那些代码相比）
您不应该期望GTM提供任何神奇的解决方案来帮助您的网站立即加载。如果您直接将8个相同的脚本（在上一个示例中使用过）添加到网站中’的源代码，结果可能会更糟。因为，因为我’ve said before, it’不是GTM本身会使您的网站变慢，’是您放入其中的物品。
然后’正是我的实验中发生的事情。
当我直接将8个跟踪脚本添加到网站时’s代码（关闭之前</head> tag), the page 放慢速度。而不是将页面加载时间增加3秒，硬编码标签在快速3G连接（单元B7-C7）上增加了600毫秒。
“Document complete”事件计时（以秒为单位）。 GTM中没有标签vs 8个硬编码跟踪标签vs 8个跟踪标签
至少根据我的实验，GTM确实确实可以帮助站点加载得更快（与对相同标签进行硬编码的测试相比）。
“Document complete”事件计时（以秒为单位）。 GTM中没有标签vs 8个硬编码跟踪标签vs 8个跟踪标签
但这并非在每种情况下都绝对正确。当我提到这个结果和对Simo的结论时，他说，在某些情况下，完全有可能在没有GTM的情况下在站点上运行JS本身，而这比使用GTM更好。因此，这是您可以将我的发现与一小撮盐结合在一起的情况之一。
继续自己进行测试。可能是你’我会发现一些有趣的东西。
标签触发的时刻很重要
您做得越晚越好。在以下内容中也对此进行了介绍和解释。 帕维尔·布雷西克（Pavel Brecik）’s guide。这里的要点是，激活标签的时间越晚，对页面加载速度的影响就越小。
我使用了相同的8个标签（FB Pixel等），并在不同的时间触发了它们。您可能已经熟悉3个与页面视图相关的触发器，即页面视图（gtm.js), DOM准备就绪 (gtm.dom), 视窗已载入 (gtm.load）。因此，我在这三个不同的时刻触发了这8个标签（例如，一个实验包括所有8个标签 页面预览, then in the next experiment, I used DOM准备就绪, etc.).
另外，我借了 帕维尔’s tip 并添加了可以触发代码的第四时刻— 1.5 seconds after 视窗已载入.
结果？
虽然在DOM Ready或Window Loaded上触发标签仅减少了一点页面加载时间，但最大的改进是 afterLoad 事件。这意味着仅在其他网页组件已经加载时才触发我的代码，因此它们不会影响初始加载过程。
“Fully loaded”事件计时（以秒为单位）。“Pageview” vs “DOM Ready” vs “Window Loaded” vs “afterLoad” triggers
为什么延迟标签首先是好的？因为网站可能只有在加载所有资源（包括脚本）之后才动态地将某些组件/元素加载到页面上。如果由于您的标签，页面加载速度变慢，则意味着那些（可能很重要的）网站元素的加载也会比预期的晚。
因此，如果延迟了某些标记并在加载了所有其他资源之后将其触发，则不会延迟其他组件的外观。
但是请记住，如果您延迟跟踪要求精确度的标记（例如Google Analytics（分析）），则这种延迟将导致报告中的更多不准确性。为什么？因为有些访问者甚至不会等待您的网站完全加载（如果花费太多时间），并且会在您解雇GA之前就离开网站。
最终结果？您的报告甚至都不知道访问者X曾经访问过您的网站。
如果延迟标签听起来像是您的解决方案，请不要’急于立即执行此操作。首先，您应该与您的团队/公司讨论哪些标签不太重要并且可以延迟。参与的每个人都必须上船。单方面的决定可能会导致意外的数据丢失甚至收入损失。
跟踪标签并不是唯一的违规者
另一组会影响页面速度（加载时）的标签是操纵 文档对象模型（DOM）Â（例如，在页面上编辑或添加新元素）。
但是，就像本指南中的其他内容一样，对页面速度的影响程度 取决于 在各种因素上。在实验10-＃13中，我尝试了几种变体：
- 在不指定位置的情况下添加元素（这意味着它们将被添加到页面底部）
- 在页面的特定部分添加元素（这意味着脚本必须检查页面并找到正确的位置（这会自动需要更多资源））。
显然，我认为事情可能有点过头了（通过使用添加元素的100-200个自定义HTML标记），但与此同时，“heaviness”这些标签的数量很低。
但是，当标签必须在页面的特定部分插入元素时，将需要更多的计算机资源。例如，如果您的脚本使用 document.querySelectorAllÂ（这意味着它会搜索页面上符合特定条件的所有元素）并遍历每个元素，这将需要来自浏览器的更多时间/资源。
在实验10和11中，我没有指定添加元素的位置，因此，GTM将其插入到<body>。这对页面加载速度没有显着影响。
在实验＃12中，我指定了要在其中注入新元素的位置。我没’t using querySelectorAll 方法。但是，即使没有这些标签，同样的100个标记（在页面的特定部分添加了元素）也增加了数百毫秒的页面加载时间。我使用的脚本相当基本：
<script>
(function() {
var h3 = document.createElement('h3');
h3.innerText = "An additional element";
var title= document.querySelector('h2');
if (title) {
title.parentElement.insertBefore(h3, title.nextSibling);
}
})();
</script>
这里’s the impact:
“Fully loaded”事件计时（以秒为单位）。空的GTM容器与100个执行基本DOM操作的自定义HTML标记
实验＃13的构建需要更多的资源。我有100个自定义HTML标记，它们正在寻找页面上的所有链接，然后在第21个元素之后，它将添加带有一些示例文本的标题3。
<script>
(function() {
var h3 = document.createElement('h3');
h3.innerText = "An additional element";
var element = document.querySelectorAll('a')[20];
if (element) {
element.parentElement.insertBefore(h3, element.nextSibling);
}
})();
</script>
此实验与＃12实验之间的区别在于，此实验是对网站元素进行迭代，检查每个元素，然后在符合条件的情况下添加一个元素。尽管webpagetest.org上的结果没有突破性（页面加载（100-200ms）略有延迟），但是使用Lighthouse（内置的Chrome网站审核工具）使事情变得更加有趣。
在台式机和移动设备上，这些标签都将2-3秒添加到了 互动时间 度量标准，这意味着在页面加载期间，浏览器非常忙于将那些Heading 3元素添加到页面中，因此，该网站可能在较长时间内对访问者没有响应。
“Time to interactive”（以秒为单位）进行更重的DOM操作时
当然，我 ’通过添加相同的脚本100次，这有点太过分了，但这仅仅是概念上的证明。也许您的容器将具有更少的可操作DOM的标签，但其影响会更大（由于其复杂性）。
第3部分：有关如何最小化Google跟踪代码管理器的提示’对页面速度的影响
现在，让’s进入您的部分’可能是最感兴趣的，将影响最小化。
我不愿意为您打破这一点，但没有灵丹妙药。有一些 可能 快-ish 获胜，但与此同时，您将不得不在团队/公司内部进行讨论，并寻求妥协（在一个方面牺牲了页面速度，在另一个方面则牺牲了页面速度— data accuracy).
＃1定期审核您的容器并寻找废弃的供应商
我记得在伦敦2019 MeasureCamp的演讲之一中听到了（我相信那是 安迪·戴维斯（Andy Davies）Â但不是100％肯定），有些审计表明，大约30％的跟踪代码（仍在页面上加载）属于公司不再使用的供应商。
想象一下：您从分析工具X迁移到新工具Z。但是工具X的代码仍在激活中。更不用说站点仍在向第三方发送（可能是个人的）数据的事实，这些标签也会影响页面速度。
识别此类跟踪代码（尤其是在大型GTM容器中）可以非常迅速地提高页面速度。
- 如果你’如果对自己自己检查脚本不满意，请开发人员为您提供他/她认为可以避免的脚本/ HTTP请求列表。
- 然后，谷歌搜索这些请求的域，并尝试确定它们属于哪些工具。
- 此外，与各个部门/同事讨论仍在使用哪些工具。
- 与大家交谈后，看看是否有 孤独 您在步骤1中从开发人员处收到的列表中的所有工具。
- 如果该工具的脚本是通过GTM实现的，请暂停这些脚本。保持这种状态（例如，保持一个月），看看是否有人抱怨数据丢失或其他原因。如果没有投诉，请从GTM中完全删除脚本。
- 如果脚本不在GTM（或其他任何代码管理解决方案中）’重新使用），请与开发者联系，并要求暂时停用这些脚本（例如，将其变成 评论）。如果一个月内没有人抱怨，请要求开发人员将其从代码中完全删除。
＃2。延迟标签不太重要（或要求准确度较低）
您投放的标签越少 所有页面 或用户定义的 页面浏览量 触发后，网页加载时间会更好（至少根据我的实验）。
现在，我完全明白你赢了’不能对所有它们都做到这一点，但是如果将这种方法应用于至少其中一些，则可能会期望性能有所提高。
根据我的测试，延迟标签在DOM Ready上启用（而不是Pageview）仅引入了一些小的改进。但是，如果您将某些标签移动到“加载窗口”时触发，则页面加载时间将显着缩短，尤其是在3G连接缓慢的情况下。
但是，这仅适用于“Document complete”事件不是在webpagetest.org报告中“Fully loaded”.
如果可能，请尝试进一步延迟某些标签。帕维尔·布雷西克（Pavel Brecik）在 他的博客文章 一种在“窗口加载”事件发生1.5秒后触发标签的技术。首先，我’ll简要解释设置，然后讨论结果。
第1步： 使用以下代码创建自定义HTML标记
<script>
(function() {
try {
window.setTimeout(
function(){
dataLayer.push({'event' : 'afterLoad'});
}, 1500);
} catch (err) {}
})();
</script>
第2步：Â Fire 这个 tag on a user-defined trigger 视窗已载入
步骤3：Â创建一个 自定义事件触发对于事件 afterLoad （区分大小写）
步骤4： 分配这个 afterLoad 自定义事件触发了您愿意在窗口加载后延迟1.5秒的那些标签。
如果我们看一下，结果会好得多 完全读取 指标。
“Fully loaded”事件计时（以秒为单位）。“Pageview” vs “DOM Ready” vs “Window Loaded” vs “afterLoad” triggers
在慢速3G连接上，此改进中断了6秒（而在快速3G连接上，节省了600毫秒）。
您如何确定哪些标签可以延迟？除非您是单人乐队，否则您绝对不会独自做到这一点。与您的队友/客户，经理等进行讨论。为了达成共识，必须听取每个职位/意见。
想象一下：
- 如果开发人员自行决定一切，他们将删除所有营销标签（或大幅延迟它们），因为他们有动力优化性能。但这将对营销工作产生负面影响，并从根本上影响收入（例如，如果您大量投资在线广告）。
- 如果营销人员自行决定一切，他们可能只会在网站上填充数十个（如果不是数百个）跟踪标记，请尽快将其触发，从而破坏该网站’s performance. That’s another extreme.
这就是为什么不同的阵营必须就如何使用延迟标签，讨论可能的影响并确定可以使用哪些标签达成一致的原因“sacrificed” to be delayed.
例如，如果您通过GTM实现了聊天小部件（尽管我认为’这是一个坏主意，此类工具应直接在代码中实现），我认为该小部件’的脚本肯定可以延迟并在x秒后触发 视窗已载入.
另一个可能的例子可能是一些再营销标签。就个人而言，我想重新定位那些实际上在页面上花费了一些有意义时间的人。停留在页面上 至少 直到 afterLoad 事件触发将是重新定位的更好指标，而不是尽快跟踪综合浏览量。再次，这只是一个建议，您需要决定’适合企业。
只要记住一件事：就会有牺牲。它可以是页面性能，也可以是数据准确性（可能还有收入）。我在这里的立场是不要盲目尝试获得完美的成绩（例如在Lighthouse中， ’s 100），而是专注于业务的最终结果。
It’关于妥协的一切。对于可以添加到站点的每个脚本，您（作为添加该脚本的GTM用户）必须考虑尽早启动该脚本而不是延迟（以性能的名义）启动该脚本的好处。
首先，您将需要决定组织内哪些可以延迟。
＃3。也许某些标签只能在某些页面上触发？
容器中是否有可在每个页面触发的标签？他们真的必须在每个页面上触发吗？也许您只是在一组着陆页上需要它们，但是由于时间有限，您选择了“All Pages” trigger?
尝试创建更精确的触发器，以将标签限制为仅一组页面（如果可能）。这样，其余网页将不会受到影响。
#4. Try avoiding heavy DOM manipulations (as a 长期解决方案)
我提到了“long term solution”字幕中的原因。 GTM绝对是测试概念验证的绝佳工具（例如，临时操作某些网页元素，看看转化率是否有所提高或其他）。但是，一旦您确认了这一想法，该改进最终应由开发人员实施并从GTM中删除。
开发人员将以更优化的方式（且可能）无需DOM操纵即可做到这一点。
这尤其适用于那些要求浏览器遍历每个元素并检查其是否符合条件的操作。尽管我的实验13没有 显着地 影响webpagetest.org结果， 互动时间 指标受到严重影响（加载时间增加了约2-3秒），这意味着该页面将在更长的时间内保持无响应。
＃5。 （面向未来）使用Google跟踪代码管理器进行服务器端跟踪
2020年1月， Google跟踪代码管理器团队在SuperWeek上宣布 他们正在使用GTM中的服务器端跟踪功能。尽管仍然没有很多细节（该功能仍处于开发的早期阶段），但对于页面速度优化而言，这似乎很有希望。
而不是在客户端加载一堆跟踪代码（这意味着访问者正在发生所有事情）’需要使用浏览器和计算机资源来处理所有负载），例如，您可以将其移至Google Cloud并大大减少访问者的任务数量’浏览器必须完成。
What can you do about it right now? Pretty much nothing, just wait. 如果你 are REALLY curious about 这个 idea in general, 大卫·瓦列霍 正计划撰写一篇有关他的GTM自定义服务器端解决方案的博客文章。请记住，他的解决方案不是官方的GTM功能。
#6. 唐’启用GTM预览模式时测量页面速度
启用后 GTM预览和调试模式，它为浏览器带来了很多额外的负担。容器中的物品越多，负载就越大。
另外，在每个dataLayer.push上，都会重新评估GTM容器中的每个变量，这意味着浏览器需要做更多的工作。
我不能’找不到通过webpagetest.org测试预览模式的影响的简便方法，但是我使用Lighthouse轻松做到了这一点。
在实验8中，我使用了一个非常重的代码和触发器的完整GTM容器，并在启用预览和调试模式的情况下测试了页面速度。结果？中的两位数 互动时间 指标（表示该网页在相当长的时间内响应缓慢）。
同样，最大FID（最大潜在的第一个输入延迟）以数千毫秒为单位，而不是数百毫秒。此指标意味着，如果访问者在页面加载期间单击链接，则单击和重定向（或单击所执行的操作）之间的潜在延迟约为3.3-3.5秒。
然后，我审核了同一容器的速度（但未启用GTM预览模式），结果要好得多（请记住，我们在这里谈论的是完整的GTM容器）。
“Time to interactive”（以秒为单位）：启用或禁用预览模式时
此外，Simo补充说，您不应使用 环境片段因为环境（例如 分期，发展）要求GTM在JS的初始加载和执行期间执行更多的工作。
＃7。在容器中进行更改后，请自己测试页面速度
希望我将介绍页面速度概念，这是一些营销人员和分析人员的另一个关注点，他们将在添加新内容之前更加自觉。
发布新的容器版本后，一个好的做法是使用Lighthouse和webpagetest.org对其进行测试。 Web Page Test还允许您限制连接速度，因此，不仅要测试快速连接，还要测试慢速连接。
＃8。始终尝试保持容器倾斜并清除不必要的物品
始终保持容器尽可能的稀薄并清除所有不必要的物品始终是一个好习惯。如果找到不相关的项目（例如标签），则将其删除。即使对速度的影响很小，’尽量保持较小总是更好的。这也将使GTM中的标签管理更加轻松’s interface.
与您的同事交谈，询问是否仍在使用X或Y供应商。如果没有，请从您的设置中删除其标签。
也许您有一些触发器或变量没有在任何地方使用（它们只是占用空间）？在这种情况下，Simo’s gtmtools.com可以帮助识别它们。
转到gtmtools.com，选择要检查的GTM帐户和容器。然后单击可视化>启动可视化。
该工具将获取容器中的所有项目并分析它们如何连接。在可视化的中间，单击 选择隐士节点…
…并且它将突出显示所有没有连接的项目，例如：
- 没有的标签’t have triggers
- 未分配给任何标签的触发器
- 其他标记，触发器或变量中未使用的变量
您删除它们以释放一些空间。尽管这（可能）不会对您的页面加载速度产生太大影响，但它会通过增加更多的呼吸空间来简化GTM的工作。
Google跟踪代码管理器与Page Speed：最后的话
然后’在另一篇GTM博客文章的结尾。’记得上一次花这么长时间写博客文章是什么时候，我觉得自己学到了很多东西。
来回学习，阅读大量资源，尝试消化所有内容，然后调整一些偏见（和偏见），绝对是一种宝贵的经验。再次感谢Simo在我遇到的一些十字路口上显示方向。
以下是我希望您从这篇博客文章中获得的主要收获：
- Although an 空的GTM容器 (added to a site) slightly impacts page loading speed, what really matters i是您放入其中的物品。
- 每种设置都不同，并且可能会有不同的违规者对您的页面速度产生负面影响。
- 异步请求也影响页面性能。即使他们不’为了阻止页面的呈现，它们仍然需要计算机资源，这可能会减慢整个加载过程。最常见的违规者是您在网站上实施的跟踪标记（例如FB像素，Twitter标记甚至是GA）。
- 在我的实验中，通过GTM添加的跟踪代码的效果要好于硬编码的标签（我的意思是页面加载指标更好）。但是根据Simo的说法，这并非绝对适用于所有情况。
- 如果可能，请延迟至少一些标签。而不是激活它们 所有页面Â （又名 页面预览），将其移动到“已加载窗口”或什至之后。这很重要，因为某些页面组件可能仅在其他资源（例如脚本）准备就绪后才加载。有了跟踪标签，“ready”一刻被推迟，这意味着一些重要的网站功能开始工作的时间比预期的要晚。
- 另外，DOM操作（当您编辑，删除，创建项目时）是非常昂贵的操作（比尝试读取现有元素的值要昂贵）。
- 服务器端跟踪将减少浏览器当前必须处理的#waitingForThatNewFeatureFromGTM的繁重工作
- It’关于妥协和牺牲的一切。组织中必须达成平衡的共识。在添加任何新的跟踪功能之前，团队/组织应权衡利弊。是的，该设置可能会影响页面加载速度。但是，这可能会为企业带来巨大的好处，并且在底线上，收入会增加吗？还是可以删除/暂停其他内容以补偿对性能的影响？
- 唐’不要盲目追求完美的页面速度得分。更好地牢记业务优先事项并尝试保持平衡。说到完美分数，在这里’s是一个得分为100的网站的示例：
该页面上唯一的一个是文本 你好，世界。没有跟踪代码，没有JavaScript，仅此而已。满分？是。这个网站会赚钱吗？不，我知道’我会走极端，但例如，如果将某个JavaScript添加到一个站点，该站点可以衡量广告的效率，然后将预算重新分配给效果最好的广告客户，从而增加收入/利润（但会对网页速度产生负面影响），我认为这是公平交易来满足业务’的主要目标，收入。 - 唐’不要贪婪和粗心。您是否真的需要在网站上实施15个跟踪供应商？您是否真的需要在网站上实现的大量自定义JavaScript代码（您在网上找到）？您是否已将该代码显示给开发人员？ （这可能会破坏您甚至不知道的事情）。
- 测试您的设置’一生中不止一次的速度ðŸ™，Don’仅在IT部门发出危险信号时才这样做。偶尔这样做以保持苗条。在对容器进行每次更改之后，页面速度测试将是完美的，但是至少在进行重大更改之后进行页面速度测试就足够了。
如果您有自己的见解可以分享，我’d喜欢听到他们的声音。通过编写本指南，我已经学到了很多东西。愿意学习更多。