A frequent comment I hear when having conversations about tag governance: “I think tags are slowing down my site, we need to figure out what’s causing this.” We then discuss the metrics they are looking at and what is leading them to believe this is their issue. And nine times out of ten, the person on the other line will tell me “tag latency!”
At this point, I have to explain why tag latency really is not the end-all-be-all of tag performance metrics and, in fact, 95% of the time has only a minuscule, if any, effect on the performance of the page.
In an effort to spread this knowledge (and hopefully help out some of you reading this in the future), let’s discuss all of the factors that come into play with site performance in the context of tags. To start, let’s kick off with the basics.
How A Web Page Loads
If you are a developer or are involved on a daily basis with the technical operations of your website, feel free to skip ahead to the next section. For all of the marketing and analytics folks, let’s start by going through a basic overview of how your website is loaded and everything that is happening when a user comes to the site.
The first thing someone does is enter a URL into their browser address bar. Now, this may be from them typing it in or clicking on a link; either way, the browser is being told: “Go to this page”. Upon this input, the browser sends a request out to what is called a DNS server in order to get the real “address”. This is the IP address of the server on which the many files that make up your site live. Once that address is returned, the browser then knows where it needs to go and ask for the ‘real stuff’ that is your web page.
From here, the browser sends a request to the server holding the website files in order to access them. It is going to request these and your server(s) will then return those files in small chunks, called packets, to be organized and pieced together by the browser.
The most important file that is returned from this initial request to the servers housing your website packets is the HTML code. You can think of this as the instructions, or guide, for how to piece everything together. The browser reads this file and then uses it as the blueprint to build all the pieces of your site in an organized way that is displayed to your users.
Now your users are able to access and use the beautifully designed web page that you put together for them. Hopefully, they like it so much that they purchase some items as a result!
The Role Tags Play
The first thing that we need to understand is what exactly website tags are.
For a typical tag on your site, it works as follows:
- A request is sent to the third-party server for something to be returned.
- The third-party server sends back more code to run on the page.
- The browser downloads, reads, and executes the new code.
- The new code executes and grabs information that is available to it, such as information about the page, information about the user, and some information that the browser is able to pass along to it, as well.
- The new code then asks the browser to send up another request to the third-party server that contains all of this information that has been compiled.
- The browser sends that request containing all the data.
- The third-party server takes in the received data and then sends back a status response that all is good and it has everything it needs.
This is the process for just one tag on your website! The same process is happening for all other tags that are on a particular web page. In addition, at the same time, the browser is also working on organizing all of the other packets that make up your site and trying to process any additional information that is being returned from all of those other servers.
Whew, if you’re feeling tired after going through all of that, imagine how the browser feels!
Now that we have a good grasp on how everything is working, from the web page being compiled and displayed to the user to the tags loading and sending information to your various marketing/advertising/analytics platforms, let’s take a closer look at the overall impact on performance.
Performance Basics - Definitions
It is first important to understand all of the key terms and main players that we will be discussing as we examine performance:
- Client: The user’s browser.
- Server: The computer(s) the client (user’s browser) is communicating with.
- Processing Time: How long it takes information to be consumed and the output to be sent. Think of this as the time it takes to “crunch the numbers”.
- Dictionary Definition: “The delay before a transfer of data begins following an instruction for its transfer”.
- Layman’s Terms: The time from the initial request being sent (leaving the page) until the response is first registered.
- Even Easier Explanation: Think of this as asking someone a question. It is the time it takes for them to think about the answer and then BEGIN to respond.
- Requests: All of those requests for information: the request to the site server for the contents of the site, tag requests for whatever information they are looking for, etc. Think of these as the questions being asked.
- CPU (Central Processing Unit): This is the ‘engine’ of your machine (computer). This is a fixed amount; i.e., you only have so much “power” to be able to do things on the machine and it can only handle so much at one time.
- Bandwidth: This is the amount of data capable of being sent and received at one time. Commonly thought of as the connection speed of the user, essentially how fast the user’s internet is. Bandwidth factors in because it determines how much of a message can be sent. Think of communicating with someone via text and only being allowed to send one word at a time vs. a sentence at a time. You’ll be able to finish the communication faster if you are able to send a sentence at a time. Same idea with requests and computing. In the texting example, you have more bandwidth in the scenario that you can send a full sentence at a time.
- Request Size: The amount of data being sent and received.
- Synchronous: Requests that must be sent, processed, and received without anything else happening.
- Asynchronous: Requests that can be sent in parallel with others and will not, by their nature, block anything else from happening
Alright, we have established what is happening when a web page is loaded as well as the definitions for the various pieces of the process. Let’s now examine the players that have a role in the production of your website. We’ll dig deeper into each player, their role in the process, and the limitations to their performance.
Performance Basics - Tags
You may be wondering how tags fit into this whole system..
Tags must be read and executed in the browser, which adds additional weight to a page. While these snippets are typically relatively small and basic, they still contribute to the pile of resources the browser must deal with to fully complete the loading of a page.
When a tag is run in the browser a request must be sent, adding to the overall request queue, of which a finite amount can be sent at one time. The speed at which requests are able to get through that queue will depend upon the bandwidth available to the user, how long the line is, as well as how long each request is taking to be responded to. Put simply, the more requests, the higher the risk of everything getting jammed up and the page load speed slowing down.
In addition, each tag request then generates a response, often additional code that must be downloaded and then run on the page. The speed at which the code can be downloaded and then run will depend again on the user’s bandwidth as well as the CPU available on the machine. If there is little to no additional capacity for the user’s machine to run the additional code, it will again delay the overall loading of a page.
In the end, the tags on your site are competing for valuable CPU and browser resources with other critical scripts that must also be run for users to have an optimal experience on the site.
Tags - Metrics That Matter
So now we understand how all of this is working and where tags fit in. We’ve also explored the ways in which tags can increase the risk of performance issues. So what are the metrics to really key in on when analyzing the tags on a site to be able to optimize and reduce the risks associated with poor page performance? Let’s explore each:
1. Tag Latency: For many organizations, this seems to be the first and last metric they will look at. Many companies I work with will set out an SLA for the latency of each platform that must be adhered to in order to stay live on the site. The unfortunate truth? In our analysis across thousands of websites, Tag Latency simply doesn’t have any significant correlation with page loading times.
When we really think about it, this shouldn’t be surprising. Going back to our definitions from earlier, the latency of a tag is the time from when the request is sent to the time in which a response begins to happen. Due to the fact that most tags today load asynchronously and don’t block anything else from being executed, they are simply another request in the queue waiting for a connection to open up to run. At the individual tag level, there’s just not enough of a strain from these small requests to make a unique difference.
This is not to say, however, that tags in aggregate don’t make a difference. If you have a slew of tags on the site, those requests in the queue add up and clog it up for everything else. In this scenario, if many requests are all very latent, it will jam up available connections and the line will get backed up, slowing down overall page load.
To address this, you’ll want to clean up any unauthorized or legacy tags on the site. Beyond this, it’s just not worth the effort to dig into tag latency on a platform by platform basis given the limited (if any) return that you will be able to see in page performance improvements.
2. Tag Size: This is the size of the file that must be downloaded by the browser for a tag to run. Size does matter. The larger the file, the more bandwidth will be required to be dedicated to the action. Beyond that, there are also CPU resources that must be used to run the code and then execute whatever commands it is making. Every file on the site (tags, site content, images, etc.) all contribute to overall page size, which is the aggregate size of all resources required for a page to load.
For optimization purposes, it’s best to think about page size in the context of the bandwidth available to users and then tag size within that framework.
Bandwidth for a user is the amount of data that can be sent at one time over their internet connection. A typical high-speed internet connection is going to be around 200-300 Mbps. On a mobile network, however, this is often significantly less and only around 2Mbps. Using the bandwidth of the mobile network as an example, each second the connection is able to download 2 million bits at maximum. If a webpage exceeds this limit by a factor of 4 (so 8 million bits need to be downloaded) the best possible load time for that page would be 4 seconds, factoring in only bandwidth.
A typical page on an ecommerce site will usually be a few Megabytes (MB). This is different from the Megabits (Mb) measure for bandwidth. To get a good comparison we’ll need to convert MB to Mb by multiplying our Megabyte number by 8 to get Megabits. Let’s use the nike.com homepage as an example:
This page is around 2.9MB (we’ll round this to 3 for simplicity purposes). This would be equivalent of 24Mb. If accessing this page on a mobile connection with only 2Mbps bandwidth, it will take at least 12 seconds for the full page and all resources to load. That’s a lot of time!
Tags factor in here because each tag contributes to the overall page size amount. In most cases, tags are quite small when compared to site content and images. Most tags will be around 10KB or so but the majority of requests will come from tags less than 1KB. Again though, when aggregating all tag requests that are happening on a page, these can add up.
When auditing the tags on a site for performance optimization purposes, look for tags that are contributing large amounts to the overall page size. These will be presenting a higher risk to page performance issues.
3. Tag Requests: Before we explored the browser limitations related to concurrent connections. There are a finite number of simultaneous requests that can be outstanding at a single time in the browser. The more requests that must be sent, received, and downloaded on a page, the more clogged up these connections become.
Think of this almost like a highway. There are only so many lanes through which cars can travel. These lanes represent the number of connections available while the cars are the requests themselves. If there are a limited number of cars on the road, traffic isn’t going to be a problem and you can reach your destination in an optimal amount of time. During rush hour when everyone is trying to get home at the same time, there are too many cars on the road and everything gets jammed up. The same happens with the connections available to a browser. The more requests, the more traffic and when traffic becomes more than the connections can support, everything gets backed up.
Optimize this by limiting the number of requests being sent on a page. Remove unnecessary and legacy tags, identify tags that are unnecessarily piggybacking and loading in even more platforms on the site (also sending more requests), and identify tags that are sending many unnecessary requests. Cleaning up the volume of tags will help you clean up the volume of requests and reduce the traffic that must be directed by the browser.
4. Tag Location: This is in reference to where tags are loading on a page. When a web page is being loaded, the browser will read through the HTML of the page from top to bottom and run each line of code in that order. The higher up in the page code that a tag is located, the earlier in the overall load sequence the tag script will be executed. Once a tag is executed, the browser is going to put its requests in the queue and the whole process of loading that platform begins.
Think about this in the context of what your users are expecting when they load a page on your site. They care about the content of the page, which is why they are coming to you in the first place. They don’t care about your analytics tracking or media audience building. As such, to optimize for user experience, you must give the user what they want!
For tags, this is a balancing act. The data collected and the functions they are providing for your business are critical. They need to run prior to the user leaving the page in order for you not to have data collection issues. At the same time, you don’t want these executing prior to all of the page content as that delays the perceived page load time from the user’s end. So how do you optimize this?
First, it is important to identify the tags that, from a resource perspective, present the largest risk to slowing page load performance. These will be the tags that either run synchronously, are very large, and/or send many requests. Identify the tags that present the biggest risk. It is then important to prioritize the tags based on the value that they bring to your organization. If you have a large spend on Facebook, for example, and are reliant on the Facebook Pixels on your site to build audiences and track the effectiveness of campaigns for optimization, then this would be a highly valuable tag to your organization. Weigh these performance risks of each platform against the business value seen and rank the platforms in order of priority. From there you can structure critical tags to load early in the page load sequence and then de-prioritize others to load after all of your page content has been given a chance to fully execute.
It’s all about controlling the amount of noise the browser needs to deal with and optimizing the resources available for more critical scripts on your page.
Auditing and optimizing tags for page performance isn’t easy. There are countless factors that go into how a tag is executing and how it could be contributing to overall page load issues. It’s important to focus on the primary factors listed here: location, tag requests, tag size, and to a much lesser extent, latency. Prioritize the platforms and structure them accordingly within your architecture. Following these steps will allow you to minimize the potential performance impact of tags and deliver your users the experience they expect when visiting your website.
Need help? We work with thousands of websites globally and over 25 of the Fortune 500 on tag management and architecture optimization. Performance auditing for tags is just the beginning. Contact us and let’s chat about how we can help your organization in all things Tag Governance.