针对 Core Web Vitals 优化代码和跟踪代码管理器。
代码是指代码段 通常通过跟踪代码管理器插入网站中的第三方代码。 跟踪代码最常用于营销和分析。
代码和跟踪代码管理器对性能的影响因网站而异。 跟踪代码管理器可以比喻为一个信封:跟踪代码管理器提供了 不过,装满容器和使用方法完全由你决定。
本文介绍了 性能和网页指标虽然本文提到了 Google 跟踪代码管理器 讨论的许多理念也适用于其他跟踪代码管理器。
对核心网页指标的影响
跟踪代码管理器会占用快速加载网页并保持网页响应能力所需的资源,从而间接影响核心网页指标。下载您网站的跟踪代码管理器 JavaScript 或进行后续调用时可能会消耗带宽。主线程上的 CPU 时间可用于评估和执行跟踪代码管理器和代码中包含的 JavaScript。
Largest Contentful Paint (LCP) 很容易在关键网页加载期间出现带宽争用。此外,阻塞主线程会延迟 LCP 呈现时间。
影响 Cumulative Layout Shift (CLS) 的方式有以下两种:在首次呈现之前延迟加载关键资源,或者跟踪代码管理器向网页注入内容。
Interaction to Next Paint (INP) 容易在主线程上发生 CPU 争用,并且我们发现跟踪代码管理器的大小与较低 INP 得分之间存在关联。
代码类型
代码对效果的影响因代码类型而异。一般来说, 代码(“像素”)的效果最佳,其次是自定义模板, 最后是自定义 HTML 代码供应商代码因其功能而异 允许。
不过请注意,代码的使用方式极大地影响了代码的效果 影响。“像素”之所以能取得出色的效果 很大程度上是因为此代码的性质 对它们的使用方式设置了严格限制;自定义 HTML 代码 效果肯定不好,但由于其自由度较高 因此它们很容易被滥用,从而对性能造成负面影响。
在考虑代码时,请注意规模: 一个标签可能可以忽略不计,但当有数十个或数百个 代码是否在同一网页上使用。
并非所有脚本都应使用跟踪代码管理器加载
通常,跟踪代码管理器不是加载 直接实现用户体验的视觉或功能方面, 例如 Cookie 通知、主打图片或网站功能。使用跟踪代码管理器执行以下操作: 加载这些资源通常会延迟其交付。这对用户而言有害无益 也可以提高 LCP 和 CLS 等指标。此外, 请注意,有些用户会屏蔽跟踪代码管理器使用跟踪代码管理器实现用户体验 功能可能会导致部分用户的网站无法正常显示。
谨慎使用自定义 HTML 代码
自定义 HTML
代码
已推出多年,在大多数网站上都被大量使用。自定义 HTML
代码允许您输入自己的代码,几乎没有限制,因为尽管名称是
此标记的主要用途是为网页添加自定义 <script>
元素。
自定义 HTML 代码有多种用途,它们对性能的影响 出现显著变化。在衡量网站效果时 大部分工具都会将自定义 HTML 代码的效果影响归因于该代码 而不是代码本身
自定义 HTML 标记可以将元素插入到周围的页面中。行为 将元素插入到网页中可能会导致性能问题 在某些情况下,也会导致布局偏移。
- 在大多数情况下,如果将元素插入到网页中,浏览器就会 必须重新计算网页上每个项的大小和位置,此过程 称为 layout。 单个布局的性能影响微乎其微,但一旦发生 过多可能会导致性能问题本次更新的影响 在低端设备以及大量 DOM 元素
- 如果在环绕声之后将可见页面元素插入到 DOM 中, 则可能会导致布局偏移。这种现象 但并不是跟踪代码管理器所独有的,因为代码通常在稍后加载 往往会插入这些代码 DOM。
考虑使用自定义模板
自定义模板支持 其部分操作与自定义 HTML 代码相同,但都是基于 提供 常见用途的 API 例如脚本注入和像素注入顾名思义 高级用户制作模板 。技术较少的用户也可以使用此模板。这通常更安全 而不是提供完全的自定义 HTML 访问权限。
由于对自定义模板施加了更严格的限制,因此这些代码 不太可能出现性能或安全问题;然而,对于这些 因此自定义模板并非适用于所有用例。
正确注入脚本
使用跟踪代码管理器注入脚本是一种很常见的用例。通过
建议使用自定义模板和
injectScript
API。
有关使用 injectScript API 转换现有自定义 HTML 的信息 代码,请参阅转换现有的 代码。
如果您必须使用自定义 HTML 代码,请注意以下几点:
- 库和大型第三方脚本应通过脚本标记加载
用于下载外部文件(例如
<script src="external-scripts.js">
),而不是直接将脚本的 复制到代码中尽管已废弃<script>
标记 因此无需单独往返下载脚本内容 增加容器大小并阻止脚本被缓存 由浏览器分开管理 - 许多供应商建议将其
<script>
代码放在<head>
。不过,对于通过跟踪代码管理器加载的脚本,此建议 这通常是不必要的:在大多数情况下,浏览器已经完成了 在跟踪代码管理器执行时解析<head>
。
使用像素
在某些情况下,第三方脚本可替换为图片或 iframe “pixels”。与基于脚本的对应项相比,像素可能支持 功能较少,因此通常被视为不太首选的实现方式 。不过,在跟踪代码管理器中使用时,像素可以更有活力地 因为它们可以通过触发器触发并传递不同的变量。它们是 是一种高效且安全的代码, 事件。像素的资源非常小(小于 1 KB), 不会导致布局偏移。
请与您的第三方提供商联系,详细了解他们在
像素。此外,您还可以尝试检查其代码中是否存在 <noscript>
标记。
如果供应商支持像素,他们通常会将这些像素包含在
<noscript>
标记之间。
像素的替代方案
Pixel 之所以流行,主要是因为曾经是最便宜的
以及最可靠的方式发出 HTTP 请求
(例如,当将数据发送到 Analytics 时)
提供商)。通过
navigator.sendBeacon()
和fetch()
keepalive
API 旨在满足同样的用例,但可以说更可靠
而不是像素。
继续使用像素没有问题,因为像素得到了很好的支持, 对性能的影响微乎其微但如果您自行构建信标 可以考虑使用其中一款 API。
sendBeacon()
通过
navigator.sendBeacon()
API 设计用于在以下情况下向网络服务器发送少量数据:
服务器响应无关紧要
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
navigator.sendBeacon(url, data);
sendBeacon()
有一个有限的 API:它仅支持发出 POST 请求,
不支持设置自定义标头。时间是
所有新型浏览器都支持此项。
fetch() keepalive
keepalive
是一个标记,用于将
API
用于发出非阻塞请求,例如事件报告和分析。时间是
将 keepalive: true
添加到传递给 fetch()
的参数中。
const url = "https://example.com/analytics";
const data = JSON.stringify({
event: "checkout",
time: performance.now()
});
fetch(url, {
method: 'POST',
body: data,
keepalive: true
});
如果 fetch() keepalive
和 sendBeacon()
看起来非常相似,这是因为它们
。事实上,在 Chromium 浏览器中,sendBeacon()
现在是基于 fetch()
keepalive
构建的。
在 fetch() keepalive
和 sendBeacon()
之间进行选择时,请务必
请考虑您需要的功能和浏览器支持。fetch() API
灵活性大幅提高不过,keepalive
支持的浏览器较少
与 sendBeacon()
相比,支持支持。
获取说明
代码通常是按照第三方供应商提供的指南创建的。 如果您不清楚供应商代码的用途,请考虑咨询知道的人员。 获得第二意见有助于确定某个代码是否有可能 性能或安全问题
我们还建议您在跟踪代码管理器中通过所有者为代码添加标签。距离很远 因为很容易忘记代码的所有者是谁,为保险起见,请删除它!
触发器
概括来讲,优化代码 触发器 操作步骤通常包括确保仅在必要的情况下触发代码 选择可在业务需求与性能成本之间取得平衡的触发器。
触发器本身是 JavaScript 代码,会增加触发器的大小和执行 跟踪代码管理器费用。虽然大多数触发因素都很小,但累积影响 相加。例如,具有大量点击事件或计时器触发器会显著增加 增加跟踪代码管理器的工作量
选择合适的触发事件
代码对性能的影响并非一成不变:一般来说,越早越好 代码触发的事件,其对效果的影响越大。资源通常是 在初始网页加载期间受限,因此会加载或执行 特定资源(或标记)将资源从其他资源中夺取。
请务必为所有代码选择合适的触发器,不过 对于需要加载大型资源或执行时间很长的代码而言尤其重要 脚本。
代码可在以下情况下触发:
网页浏览量
(通常为 Page load
、DOM Ready
、Window Loaded
),或
自定义事件为避免影响网页加载,建议触发
非必需标记放在 Window Loaded
之后。
使用自定义事件
自定义事件
触发触发器,以响应
Google 跟踪代码管理器的内置触发器。例如,许多代码都使用网页浏览量
触发器;不过,
DOM Ready
到Window Loaded
的时间段可能很长
网页,这可能会在代码触发时难以进行微调。自定义
事件提供了解决方案。
要使用自定义事件,请先创建自定义事件触发器并更新代码 使用此触发器。
要触发触发器,请将相应的事件推送到数据层。
// Custom event trigger that fires after 2 seconds
setTimeout(() => {
dataLayer.push({
'event' : 'my-custom-event'
});
}, 2000);
使用特定的触发条件
使用具体的触发条件有助于避免在不必要的情况下触发代码。 尽管有多种方法可以应用这一概念,但其中一种是最简单的, 您可以采取以下实用措施:确保代码仅在 实际用量
内置变量 也可以添加到触发条件中,以限制代码触发。
但请注意,设置复杂的触发条件或异常 处理时间本身,因此不要过于复杂。
在适当的时间加载跟踪代码管理器
调整跟踪代码管理器自身的加载时间会对 性能无论触发器的配置方式如何, 在跟踪代码管理器加载后尽管为品牌和品牌选择好的触发因素很重要, 具体代码(如上所述),在加载代码时进行试验 通常可以产生同等或更大的影响 将会影响页面上的所有代码
稍后加载跟踪代码管理器会为其增加一层控制,避免将来 性能问题,因为它可以防止跟踪代码管理器用户无意中加载 过早添加代码,而没有意识到其可能产生的影响。
变量
变量用于从网页读取数据。它们在触发器中很有用, 代码中。
与触发器一样,变量会导致 JavaScript 代码被添加到跟踪代码管理器中, 因此可能会导致性能问题变量可以是相对简单的内置变量 例如,可读取部分网址、Cookie、数据层或 DOM 的类型等。 或者,它们可以是自定义 JavaScript,基本上没有功能限制。
让变量简单明了并尽可能减少,因为它们需要进行评估 。移除不再使用的旧变量 同时缩减跟踪代码管理器脚本的体量及其处理时间 用途。
跟踪代码管理
高效使用代码将降低出现性能问题的风险。
使用数据层
数据层“包含” 您想要传递给 Google 跟踪代码管理器的所有信息”。更多 具体而言,它是一个 JavaScript 对象的数组,其中包含有关 页面。它还可用于触发代码。
// Contents of the data layer
window.dataLayer = [{
'pageCategory': 'signup',
'visitorType': 'high-value'
}];
// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});
// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});
虽然 Google 跟踪代码管理器可以在没有数据层的情况下使用,但 。数据层提供了一种整合数据的途径 可供第三方脚本访问的单个位置 以便更好地了解其使用情况这样做有助于减少 冗余变量计算和脚本执行。使用数据层 控制代码访问的数据,而不是为代码提供完整的 JavaScript 变量或 DOM 访问。
移除重复和未使用的标记
如果某个标记包含在 以及通过跟踪代码管理器注入。
未使用的代码应暂停或移除,而不是使用 触发器异常。 暂停或移除代码会从容器中移除代码;屏蔽广告 错误。
移除未使用的代码后,您还应该 并检查是否只有那些 代码。
使用允许列表和拒绝列表
允许和拒绝列表 您可以针对代码、触发器和 变量。这可用于帮助实现最佳性能 做法和其他政策。
允许列表和拒绝列表通过数据层进行配置。
window.dataLayer = [{
'gtm.allowlist': ['<id>', '<id>', ...],
'gtm.blocklist': ['customScripts']
}];
例如,您可以禁止任何自定义 HTML 代码、JavaScript 变量或直接的 DOM 访问。这意味着,您只能使用像素和 可以结合使用。虽然这确实有一定的限制性 可以带来更加高效、更安全的跟踪代码管理器实现方案。
考虑使用服务器端代码植入
改用服务器端代码植入并非易事,但值得一试 特别是对于那些希望更好地控制其广告资源的大型网站, 数据。服务器端代码植入从客户端移除供应商代码 将客户端的处理工作分流到服务器
例如,使用客户端代码植入时,将数据发送到多项分析 需要客户端为每个端点发起单独的请求。 相比之下,使用服务器端代码植入时,客户端只需向 然后将这些数据转发到服务器端容器, Google Analytics 账号。
请注意,服务器端代码植入仅适用于部分代码;标记 兼容性因供应商而异。
有关详情,请参阅服务器端简介 代码植入。
容器
跟踪代码管理器通常允许使用多个实例或“容器”在其内部 设置。这样,在一个代码内即可控制多个容器 经理账号。
每个网页只能使用一个容器
使用多个 容器 会造成严重的性能问题,因为它会导致 额外开销和脚本执行。至少它会复制 作为容器的一部分投放时 JavaScript 不能在不同容器之间重复使用。
很少有效地使用多个容器。不过 如果控制得当,此方法可发挥效用,具体包括:
- “前期负载”较少而“后期负载”较重container, 而不是使用一个大容器
- 有一个供技术较少的用户使用的受限容器, 一种受限制但受到更严格控制的容器,用于容纳无法使用的代码 受限容器中的 Pod
如果您必须在每个网页上使用多个容器,请遵循 Google 跟踪代码管理器 关于设置多个 容器。
根据需要使用单独的容器
如果您针对多个媒体资源(例如,一个 Web 应用和一个 (移动应用中的容器)- 您使用的容器数量可能会对您的工作流程造成影响, 效率。它还会影响性能。
一般来说,一个容器可以有效地用于 例如,虽然 移动应用和 Web 应用的功能可能类似, 应用的结构将有所不同,因此可以更有效地管理 通过单独的容器进行通信
如果过于广泛地尝试重复使用单个容器,通常会导致不必要的增加 通过强制采用复杂逻辑来降低容器的复杂性和大小 来管理代码和触发器
关注容器大小
容器的大小由其代码、触发器和变量决定。 虽然小容器可能仍会对网页性能产生负面影响,但大容器 基本上肯定会的
在优化代码时不应将容器大小作为首选指标 使用情况;但大型容器通常是一个警告信号, 未得到很好的维护,可能会被滥用。
Google 跟踪代码管理器 limits 容器 大小更改为 200 KB,并且当容器大小从 140 KB 开始时,就会发出警告。不过, 大多数网站都应力争使其容器远远小于此大小。对于 那么,中位数网站容器大约为 50 KB。
要确定容器的大小,请查看响应的大小
由 https://www.googletagmanager.com/gtag/js?id=YOUR_ID
返回。这个
包含 Google 跟踪代码管理器库以及
容器。Google 跟踪代码管理器库本身的大小就大约为 33 KB。
压缩。
为容器版本命名
一个容器 版本 是容器内容在特定时间点的快照。使用 并附上关于有意义的简短说明 内发生的更改大有帮助,让您更轻松地调试未来的性能 问题。
标记工作流
请务必管理对代码的更改,确保它们没有 对网页性能的负面影响。
在部署前测试代码
在部署前测试代码有助于发现问题(性能和 否则)。
测试代码时需要考虑的事项包括:
- 代码能否正常工作?
- 此标记是否会导致任何布局偏移?
- 代码是否会加载任何资源?这些资源有多大?
- 代码是否会触发长时间运行的脚本?
预览模式
预览模式 测试代码更改,无需将更改部署到 公开优先。预览模式包含一个调试控制台, 有关标记的信息
Google 跟踪代码管理器的执行时间会有所不同(稍慢) 在预览模式下运行时,这样做会产生额外的开销, 调试控制台中的信息。因此,比较网页指标的 建议不要在预览模式下收集到在生产环境中收集的。 不过,这种差异应该不会影响代码的执行行为 。
独立测试
另一种代码测试方法是设置一个包含 包含单个标记(即您正在测试的代码)的容器。此测试设置较少 贴近现实,并且无法捕捉一些问题(例如,某个代码是否会导致布局 - 然而,通过这种方法,您可以更轻松地分离和衡量 对脚本执行等操作进行标记。了解《电讯报》是如何使用 通过隔离方法改进 效果 第三方代码中
监控代码效果
Google 跟踪代码管理器监控 API 均可使用。 来收集有关 次 特定代码系统会将此信息报告给 选择。
有关详情,请参阅如何构建 Google 跟踪代码管理器 监控。
容器更改需要获得批准
第一方代码通常会在部署之前接受审核和测试 - 对代码一视同仁添加两步验证 验证, 需要管理员批准才能更改容器 这个。如果您不想要求两步验证 仍想关注更改,则可以设置容器 通知发送到 接收与您选择的容器事件有关的电子邮件提醒。
定期审核代码使用情况
使用代码还存在的一大挑战是,代码会在不同时段 时间:标签添加但很少删除。定期审核标记是一种 来扭转这种趋势。理想的频率取决于 您网站的代码更新频率。
为每个标签添加标签,以便于识别其所有者 可对该代码做出响应,并能说明是否仍需要它。
审核代码时,不要忘记清理触发器和变量 。它们也很容易导致性能问题。
有关详情,请参阅将第三方脚本 控制。