The easiest CRO you can do is via Google Tag Manager

CASE STUDY: The easiest CRO you can do is via Google Tag Manager

Business summary: By changing couple of triggers in Google Tag Manager it's possible to significantly decrease page load time. Very significantly!

You might have a strange look in your face when reading the title. Conversion rate optimization and Google Tag Manager? Yes and YES! Bear with me for couple more lines and you might be surprised how simple it can be. As we all know site speed matters and couple of seconds can cost you a fortune.. And this is exactly what we're going to do in this post. Still not believing? Don't be surprised if you'll be able to save more than 2 seconds from page load time. Sorry, did I just spoil the article? Probably!

3rd party scripts

Have you ever heard of 3rd party retargeting platforms such as Criteo, Facebook or RTB House? And how do they want their scripts to be triggered? If so, you can directly skip to the next paragraph. For those of you who are not familiar with the topic, here's explanation of what's the case.

Every single platform wants its script, which collects data, to be fired as soon as possible. And no one can blame them for it. Well, maybe yes, but let's assume not at least at the beginning of this post :). They want to collect as many cookies as possible for further retargeting. That's the reason why there are recommendations from their side to place script into HTML <head> section. If you use any tag management solution "the best" practice is to fire the script as soon as possible. We're going to explain what does it mean it the following lines.

GTM events

At first let's repeat what default events we have in Google Tag Manager and quickly explain what do they mean. Based on them it's possible to create triggers that will fire retargeting scripts. There are three of them:

1. Page View - this is the earliest possible moment you can fire a tag. It means that GTM container has been loaded and immediately after that it's possible to fire a tag.

2. DOM Ready - it means that HTML content has been loaded, parsed and it's ready to start rendering the page. The browser just knows the paths to all css files, images, javascripts, etc. In this moment, you don't see any content you can interact with. The browser starts to download all mentioned assets.

3. Window Loaded - this event is fired when website has been fully rendered.

To sum it up the image below shows the order and timing of GTM events. More detailed explanation is available in Simo Ahava's article.

Order of default GTM events

Tested platforms

For the purposes of this post we'll work with three following platforms: Criteo, Facebook and because I live in Czech I picked Sklik which is major local player.

And now, let's have a look on recommended implementation guidelines that platforms provide:

Criteo

Criteo implementation guide

Facebook

Facebook implementation guide

Sklik

Recommendation is to place javascript code directly into HTML or via GTM. There's no guideline which trigger should be used. I will assume that it's same as in case of Criteo and Facebook. Either "DOM Ready" or "Page view" trigger.

As mentioned in the beginning, majority of platforms recommend firing their script as soon as possible, which in Google Tag Manager means to either use "Page View" or "DOM Ready" event as trigger.

And here comes a little game with triggers we're going to play. At first we'll load the page with no 3rd party scripts. Then we'll use three default GTM events and then one custom trigger called "After load". To create such a trigger, it's necessary to create custom HTML tag in Google Tag Manager using the following code:

GTM custom HTML tag function

What it does is that 1,5 seconds after page has been fully rendered it pushes and extra event into dataLayer, based on which I created a custom trigger. This is what you should see in GTM preview mode after having such a trigger.

GTM debug mode with triggers

Methodology

Two metrics will be followed: Page load time and time when the first webpage content is rendered (TWCR) and it's possible to interact with website itself.

TWCR is metric I invented only for the purpose of this article. I'm sure there's an official name for it, so don't sacrifice me for it. For the sake of the post, it should be OK.

Image below shows what TWCR means and when the time is measured. In case of my website the page isn't fully rendered because I use javascript function for short (and hopefully cool :)) transition animation.

TWCR

Both of metrics will be measured in Google Chrome's developers console. We will simulate two device types. Desktop with wi-fi connection and mid-tier mobile phone with fast 3G connection. The results may be surprisingly different. For every device and trigger combination I've conducted 50 unique measurements with cleared cache for every measurement, with no browser add-ons and only one tab opened. It's 500 measurements in total.

Results

Let's have a look at results.

Device Desktop Mobile
GTM trigger Page load time [s] TWCR [s] Page load time [s] TWCR [s]
No pixels 0,91 1,62 4,14 4,65
Page View 1,51 1,99 6,45 7,31
DOM Ready 1,45 2,14 7,34 7,71
Window Loaded 1,31 2,11 4,93 5,76
After Load 1,13 1,67 4,31 4,67

Quite a difference, right? What a small change in used triggers can do with page load time. For easier understanding the data look at the bar charts below.

Desktop Page Load time

And differences are even bigger on the mobile. I'd say almost game-changing.

Mobile Page Load Time

As obvious from both device types the worst trigger in my case is DOM Ready. Window Loaded trigger seems like a slightly better option, but it still increases load time comparing to "No pixels" version. Even though the page is supposed to be fully loaded, it doesn't have to be usable at this moment. It depends on many things and one of them is the amount of javascript that has to be processed, which requires a lot of hardware performance. And if your device isn't cutting edge phone that can launch a rocket into space, you might lose a precious time.

On the other hand, if you create an "After load" trigger, it's possible to get almost at the same TWCR and Page Load time as when you're not firing any retargeting scripts. Win-win. Or maybe win-draw. I can imagine arguments from retargeting platforms that they will lose significant cookies volume, but that's a different story whether we want to retarget users who didn't spent even couple of seconds on the website. And whether retargeting as type of advertising works at all when we look at it from incremental point of view :).

Interpretation

Triggers you use in GTM really matters! I have pretty decent web when it comes to its site speed. Once I implemented JUST three (it's quite common that websites use more than 5 of them) retargeting codes by platforms recommendation its speed performance got worse pretty drastically. I leave it up to you whether almost 3 seconds on mid-tier mobile device is a lot or not. Mhmhm...No, I don't. It's hell of a lot.

There's one of many case studies about how much page load time affects conversion rate. Try to experiment with it and you might be surprised as much as I was with the results.

Happy triggering :)

Related posts: