Why you should delay firing your analytics tags

Why you should delay firing your analytics tags

If you run a website you’ll no doubt be aware of how important your page speed is: for ranking on search engines, for user experience, for conversions, for everything. You’ve probably been inundated with recommendations and pleas that you need to do more to speed up your website.

We’ve conducted a series of tests on delaying analytics tagging and its impact on website loading speed. We found that delaying all analytics tags until the page is fully loaded could shave off 0.5-2 seconds from your page’s load time (as perceived by page speed tools and not real users).

Here is one before/after example:

Why does this happen?

Here’s how a page load works:

  1. A browser requests a URL, for example your homepage.
  2. Your server delivers this page as an HTML file.
  3. The browser then starts requesting any resources mentioned in the HTML file that it thinks it needs to render the page. This probably includes images, Javascript files, CSS files, libraries, fonts etc. If you just paste your Google Analytics, Facebook Pixel and other tracking codes on your website, they will be included in this initial bundle. If you use Google Tag Manager and set these tags to fire as soon as possible (using the All Pages trigger), same story.
  4. Once the browser has finished downloading all the assets, it is able to finish rendering the page. It’s only at this point that it triggers the onloadevent that says the page’s initial rendering is truly finished.

We’ve found that on step 3, one or more tracking tags often take a while to fire. When this happens, it delays the firing of the onload event.

Who cares about the onload event?

Users do not care since they might have all visible content loaded well before the onload event fires. However, for an automated tool that scans your page, it might make a difference. Every search engine takes your page load speed into account and while they measure performance across a range of factors, making the window finish loading as quickly as possible is certainly going to improve an automated test, if only slightly.

Yes it is “teaching to the test”. We are reducing the perceived load time (to a bot) without necessarily making the website faster (for users). We’re cooking the books so to speak. But there is a UX argument for this. To truly build our pages for users, we want to first render the things that the user has asked for (ie. the visible page) and only then worry about the things that help us run our business (ie. tracking tags). The only downside is that any user who leaves the website very quickly will not be included in your Google Analytics, your remarketing lists, your Facebook reports etc. However we’d argue that a visitor that left instantly is not a quality user anyway and does not contribute that much to your reports or remarketing lists. The traditional tracking method does not avoid this either.

Over the course of our testing, we have not noticed a drop in Google Analytics traffic.

How do I implement this?

If you don’t use a tag manager then you would need to write custom code, because every tag’s Javascript is set to fire it as quickly as possible. But hopefully you use a tag manager, riiiiight?

Here’s an example of implementing this in Google Tag Manager. Start by creating a new trigger that fires on all Window Loaded events. This is the same as the onload Javascript event.

Next, change any tag that’s set to fire on all pages to fire on this trigger instead

And that’s it! You have now delayed tags and helped to ramp up the speed of your website.

Got a question?

For something quick, the best place to ask would be on Twitter or in our Facebook group (you'll need to join the group but it’s a one-click process).