Published: July 29, 2021
Tags are snippets of third-party code that are inserted into a site, typically with a tag manager. Tags are most commonly used for marketing and analytics.
The performance impact of tags and tag managers varies wildly across sites. Tag managers can be compared to an envelope: the tag manager provides a vessel, but what you fill it with and how you use it is mostly up to you.
Here, we discuss techniques for optimizing tags and tag managers for performance and Core Web Vitals. Although this document references Google Tag Manager, many of the ideas discussed are applicable to other tag managers.
Impact on Core Web Vitals
Tag Managers can often impact your Core Web Vitals indirectly by using up resources needed to load your page quickly and keep it responsive. Bandwidth can be spent downloading the tag manager JavaScript for your sites, or the subsequent calls this makes. CPU time on the main thread can be spent evaluating and executing JavaScript contained within the tag manager and the tags.
Largest Contentful Paint (LCP) is vulnerable to bandwidth contention during the critical page load time. Additionally, blocking the main thread can delay the LCP render time.
Cumulative Layout Shift (CLS) can be impacted, either by delaying loading critical resources before the first render, or by tag managers injecting content into the page.
Interaction to Next Paint (INP) is susceptible to CPU contention on the main thread, and we have seen a correlation between the size of tag managers and poorer INP scores.
Choose the right tag type
The impact of tags on performance varies by tag type. Generally speaking, image tags ("pixels") are the most performant, followed by custom templates, and lastly, custom HTML tags. Vendor tags vary depending on the functionality they allow.
Keep in mind that how you use a tag greatly influences its performance impact. "Pixels" are highly performant largely because the nature of this tag type imposes tight restrictions on how they can be used; custom HTML tags aren't necessarily always bad for performance, but due to the level of freedom they offer users, they can be easy to misuse in a way that is bad for performance.
When thinking about tags, keep scale in mind: the performance impact of any single tag may be negligible—but can become significant when tens or hundreds of tags are used on the same page.
Not all scripts should be loaded with a tag manager
Tag managers aren't typically the best way to load resources that implement immediate visual or functional aspects of the user experience, such as cookie notices, hero images, or site features. Using a tag manager to load these resources typically delays their delivery. This is bad for the user experience and can also increase metrics, such as LCP and CLS.
In addition, some users block tag managers. Using a tag manager to implement UX features may result in a broken website for some of your users.
Be careful with Custom HTML tags
Custom HTML
tags
have been around for many years and are heavily used on most sites. Custom HTML
tags allow you to enter your own code with few restrictions as, despite the name,
the main use of this tag is to add custom <script> elements to a page.
Custom HTML tags can be used in a wide variety of ways and their performance impact varies significantly. When measuring the performance of your site, be aware that most tools attribute the performance impact of a Custom HTML tag to the tag manager that injected it—rather than the tag itself.
Custom HTML tags can insert an element into the surrounding page. The act of inserting elements into the page can be a source of performance issues, and in some cases, also cause layout shifts.
- In most situations, if an element is inserted into the page, the browser must recalculate the size and position of each item on the page. This process is known as layout. The performance impact of a single layout is minimal, but when it occurs excessively it can become a source of performance issues. The impact of this phenomenon is larger on lower-end devices and pages with a high number of DOM elements.
- If a visible page element is inserted into the DOM after the surrounding area has already been rendered, it can cause a layout shift. This phenomenon is not unique to tag managers—however, because tags typically load later than other parts of the page, it's common for them to be inserted into the DOM after the surrounding page has already been rendered.
Use Custom Templates
Custom templates support some of the same operations as Custom HTML tags but are built upon a sandboxed version of JavaScript that provides APIs for common use cases like script injection and pixel injection. As the name implies, they allow a template to be created, by a power user who can build this with performance in mind. Less technical users can then use the template. This is often safer than providing full Custom HTML access.
Due to the greater restrictions imposed on custom templates, these tags are much less likely to exhibit performance or security issues. For these same reasons, custom templates don't work for all use cases.
Inject scripts correctly
Using a tag manager to inject a script is a very common use case. The
recommended way to do this is to use a Custom Template and the
injectScript
API.
For information on using the injectScript API to convert an existing Custom HTML tag, see Convert an existing tag.
If you must use a Custom HTML tag, remember:
- Libraries and large third-party scripts should be loaded with a script tag
(for example,
<script src="external-scripts.js">) that downloads an external file, rather than directly copy-pasting the script's contents into the tag. Although forgoing use of the<script>tag eliminates a separate round-trip to download the script's contents, this practice increases container size and prevents the script from being cached separately by the browser. - Many vendors recommend placing their
<script>tag at the top of the<head>. However, for scripts loaded with tag manager, this is often unnecessary. In most situations, the browser has already finished parsing the<head>by the time that the tag manager executes.
Use pixels
Sometimes, third-party scripts can be replaced with image or iframe pixels. Compared to their script-based counterparts, pixels may support less functionality, so are often seen as a less-preferred implementation. However, when used inside tag managers, pixels can be more dynamic as they can fire on triggers and pass different variables.
Pixels are the most performant and secure type of tag because there is no JavaScript execution after it's fired. Pixels have a very small resource size (less than 1 KB) and don't cause layout shifts.
Check with your third-party provider for more information on their support for
pixels. Additionally, you can try inspecting their code for a <noscript> tag.
If a vendor supports pixels, they often include the pixel within the
<noscript> tag.
Alternatives to pixels
Pixels became popular largely because at one time they were one of the cheapest
and most reliable ways to make a HTTP request in situations where the server
response is not relevant ( for example, when sending data to analytics
providers). The
navigator.sendBeacon()
and fetch() keepalive
APIs are designed to address this same use case but are arguably more reliable
than pixels.
There is nothing wrong with continuing to use pixels—they are well supported and have minimal performance impact. However, if you are building your own beacons, it's worth considering using one of these APIs.
sendBeacon()
The
navigator.sendBeacon()
API is designed for sending small amounts of data to web servers in situations
where the server response does not matter.
const url = "https://example.com/analytics";
const