Blog Post

The Holes in Google Tag Manager’s Async Loading

Published
April 14, 2015
#
 mins read
By 

in this blog post

At Catchpoint, we often give the advice to load third party tags asynchronously in order to prevent them from affecting your site’s overall performance. This advice almost always holds true, but there are edge cases where it might not get the desired outcome.

A lot of people in the web development and operations assume that tags that implement “asynchronous loading” will not block the “onload” event of the page. However, that is not necessarily true. A lot of third parties simply implement code that loads their resources asynchronously without blocking other tags from loading on the page – but they will still block the onload event from firing.

The blocking of that onload event can have some negative consequences. From a usability perspective, most browsers will show the status bar displaying the “Connecting” message, the tab might display the spinning wheel, and in some browsers the mouse pointer will be spinning as well.  Here is an example of onload event hanging on Chrome 41.

onload event hang

But this browser behavior might be the least of your problems. The biggest problem is any website logic that triggers on the onload event will be negatively impacted – this could be sliders, third party tags, etc. Another issue is that monitoring solutions – synthetic or Real User Measurement (RUM) – rely on the onload event to tracking whether the page loaded correctly, as there is no standard today for tracking the status “the page is working for the user.”

Tag management solutions aim to help with the management of third party tags, and to mitigate the risk of performance issues. One free solution is Google Tag Manager 2.0, which is trusted by more than 433K websites (based on Datanyze).

When troubleshooting an issue in which a client was impacted by a recent Facebook outage, we noticed something strange: the Facebook outage had caused problems loading the client’s website despite the fact that the Facebook tag was being loaded via Google Tag Manager. Facebook tags, like Google’s, also load asynchronously.

To isolate the problem, we made a test page that loads the Facebook connect tag via Google Tag Manager, and another that loads it directly on the webpage. When Facebook’s service and the route from it were healthy, things looked great; the tag did not impact page load.

Now, we would be silly to stop there, so we decided to cause connect.facebook.net to hang by changing both tags to attempt to connect to port 82, thus causing the request to hang since that port is not open for HTTP traffic.

Here are the results on the Network Tab of Chrome Developer Tools with the Facebook tag placed directly on the page:

Facebook tag directly on page

The Facebook tag clearly impacts the onload event (represented by the vertical red line on the right), while it is loading async.

Here are the results on Chrome Developer Tools with the tag loaded via Google Tag Manager:

GTM2

As you can see, even with Google Tag Manager, the onload event is still contingent upon the loading of the Facebook connect tag. (Note: we did our testing in Chrome 41, Safari 8, Firefox 37, and IE 11. The results were the same for all browsers.)

Google does clearly state that the solution will not impact loading of other tags, but it does not claim it will alleviate the onload issues. Taken from the Google documentation:

“Google Tag Manager is an asynchronous tag, meaning that when it executes, it does not block other elements from rendering on the page. It also causes the other tags that are deployed via Google Tag Manager to be deployed asynchronously, meaning that a slow loading tag won’t block other tracking tags.”

To sum up, “async loading” does not mean the onload event will not be blocked. Facebook and Google do implement async loading, but the onload event will still be delayed when those tags hang. Google Tag Manager is great for making it easy to manage multiple tags with the various rules and ability to switch tags on and off, and does improve user experience by ensuring that third parties do not impact the loading of any content that comes before the onload event. However, one of the biggest values users expect of tag management solutions is to ensure that the onload event itself (and anything that is contingent upon its firing) is not impacted.

The lesson here for everyone is to ensure that your needs are clearly outlined, and that the third party’s solution clearly matches those needs. Do not assume from their language that it does meet your requirements – test them thoroughly!

At Catchpoint, we often give the advice to load third party tags asynchronously in order to prevent them from affecting your site’s overall performance. This advice almost always holds true, but there are edge cases where it might not get the desired outcome.

A lot of people in the web development and operations assume that tags that implement “asynchronous loading” will not block the “onload” event of the page. However, that is not necessarily true. A lot of third parties simply implement code that loads their resources asynchronously without blocking other tags from loading on the page – but they will still block the onload event from firing.

The blocking of that onload event can have some negative consequences. From a usability perspective, most browsers will show the status bar displaying the “Connecting” message, the tab might display the spinning wheel, and in some browsers the mouse pointer will be spinning as well.  Here is an example of onload event hanging on Chrome 41.

onload event hang

But this browser behavior might be the least of your problems. The biggest problem is any website logic that triggers on the onload event will be negatively impacted – this could be sliders, third party tags, etc. Another issue is that monitoring solutions – synthetic or Real User Measurement (RUM) – rely on the onload event to tracking whether the page loaded correctly, as there is no standard today for tracking the status “the page is working for the user.”

Tag management solutions aim to help with the management of third party tags, and to mitigate the risk of performance issues. One free solution is Google Tag Manager 2.0, which is trusted by more than 433K websites (based on Datanyze).

When troubleshooting an issue in which a client was impacted by a recent Facebook outage, we noticed something strange: the Facebook outage had caused problems loading the client’s website despite the fact that the Facebook tag was being loaded via Google Tag Manager. Facebook tags, like Google’s, also load asynchronously.

To isolate the problem, we made a test page that loads the Facebook connect tag via Google Tag Manager, and another that loads it directly on the webpage. When Facebook’s service and the route from it were healthy, things looked great; the tag did not impact page load.

Now, we would be silly to stop there, so we decided to cause connect.facebook.net to hang by changing both tags to attempt to connect to port 82, thus causing the request to hang since that port is not open for HTTP traffic.

Here are the results on the Network Tab of Chrome Developer Tools with the Facebook tag placed directly on the page:

Facebook tag directly on page

The Facebook tag clearly impacts the onload event (represented by the vertical red line on the right), while it is loading async.

Here are the results on Chrome Developer Tools with the tag loaded via Google Tag Manager:

GTM2

As you can see, even with Google Tag Manager, the onload event is still contingent upon the loading of the Facebook connect tag. (Note: we did our testing in Chrome 41, Safari 8, Firefox 37, and IE 11. The results were the same for all browsers.)

Google does clearly state that the solution will not impact loading of other tags, but it does not claim it will alleviate the onload issues. Taken from the Google documentation:

“Google Tag Manager is an asynchronous tag, meaning that when it executes, it does not block other elements from rendering on the page. It also causes the other tags that are deployed via Google Tag Manager to be deployed asynchronously, meaning that a slow loading tag won’t block other tracking tags.”

To sum up, “async loading” does not mean the onload event will not be blocked. Facebook and Google do implement async loading, but the onload event will still be delayed when those tags hang. Google Tag Manager is great for making it easy to manage multiple tags with the various rules and ability to switch tags on and off, and does improve user experience by ensuring that third parties do not impact the loading of any content that comes before the onload event. However, one of the biggest values users expect of tag management solutions is to ensure that the onload event itself (and anything that is contingent upon its firing) is not impacted.

The lesson here for everyone is to ensure that your needs are clearly outlined, and that the third party’s solution clearly matches those needs. Do not assume from their language that it does meet your requirements – test them thoroughly!

This is some text inside of a div block.

You might also like

Blog post

Preparing for the unexpected: Lessons from the AJIO and Jio Outage

Blog post

It’s time to stop neglecting the elephant in the room: Performance Matters!

Blog post

The Need for Speed: Highlights from IBM and Catchpoint’s Global DNS Performance Study