DOM Ready trigger in Google Tag Manager: Quick Guide

Disclaimer: This blog post is very much related to another article about the Window Loaded trigger.

When a page loads (and you have enabled GTM preview and debug mode), you will see 3 standard events: Page view, DOM Ready and Window Loaded (if you see just 2, this is bad and you should read this guide to fix the issue).

What do those events mean? In this blog post, I’ll quickly explain what DOM Ready event is and why should you care about it.

What is DOM Ready trigger in GTM?

DOM Ready event appears in the preview mode (and in Data Layer) when the browser finishes constructing the website’s document object model (DOM) from HTML. Sounds confusing, I know. Bear with me.

Simply put, when the browser renders the page elements and their values can be accessed (e.g. for scraping by Google Tag Manager), then the DOM Ready event appears.

However, this does NOT mean that the page has fully loaded. There might still be some elements on a page that will be loaded only after particular scripts do their job.

You can find this trigger by going to Triggers (in GTM interface) > New > Trigger Configuration > DOM Ready. If you want to use that one any page, leave all other settings as they are and save the trigger.

If you want to use this trigger only on certain pages, you can choose Some DOM Ready Events and then enter the condition, e.g. Page Path contains /product/ (this is obviously just an example, you’ll need to come up with a condition that fits your needs).

What is DOM? I Quick Introduction

In order to understand what DOM Ready trigger in GTM is, first you need to have at least a very basic understanding of what DOM is in general. Document Object Model (a.k.a. the DOM) is a dynamic tree-like hierarchical representation of the website’s document. It allows manipulating the website’s document, get values of current website elements, add new, edit or remove existing ones.

If you go to any website and open its source (e.g. CTRL+U on Chrome (Windows)), you’ll see the HTML code of the page. This is the code that a developer wrote to make the website what it looks like right now.

But it does not look very dynamic, does it?

But if you go back to that very same website and open developer tools (Chrome on Windows: press F12, Chrome on Mac: Command + Option + I), you’ll see a more dynamic representation of the website’s code. If not, switch to the Elements tab.

There are nodes that can be expanded or collapsed (by clicking dark triangles), many nodes have children that can have their own children, nodes can have multiple children, etc. It’s a dynamic tree-like representation of website’s documents. You’re inspecting the HTML DOM here.

As I have mentioned before, DOM allows not only to view/inspect website elements but to manipulate them as well. The easiest and most down-to-earth way to edit nodes in the DOM is to do a double click on a certain node and then change its value or delete/edit/add attributes to an element.

But this is not very scalable and useful. Instead, there should be some better way to do that, right? Yes. DOM supports a bunch of methods that enable developers (and you, if you are skilled enough) to add, edit, delete elements.

As for reading values, getElementById(“some_id”) method will return you the first website element that matches a some_id ID. In the screenshot below, you can see the command (1st row) and the returned element (2nd row).

Another example could be querySelector(), that returns the first website element that matches a certain CSS Selector defined by you.

To sum up, when the browser builds the DOM, you could use it to manipulate the website’s content (or retrieve a certain value). Therefore, when the DOM is ready to be used, the DOM Ready event is fired and you can see it in the Preview and Debug mode. This is why the event is called like that.

When should I use DOM Ready trigger?

A couple of quick examples come to my mind.

Example #1. If you asked a developer to push some custom data to the Data Layer, e.g. e-commerce data, and that data is placed BELOW the GTM container snippet, and you were planning to fire the tag on a Page view trigger, use the DOM ready trigger instead.

Why? Because if the dataLayer.push code snippet with the custom data is added below the GTM snippet, custom data will not be available on the Page view event. You can start using that from DOM Ready and other subsequent events.

Example #2. If you want to use DOM Element Variable or some other methods that will return a value of a particular page element.

If you want to pass the value of that website element with a tag (e.g., GA Pageview tag), you CANNOT fire the tag before the DOM Ready event. Use the DOM Ready trigger. You can also most definitely fire it later (e.g. on click or on Window Loaded), but definitely do not fire it on Pageview.

Does DOM Ready improve my page loading speed?

Not much. As for the page speed, delaying tags from the Page view to DOM Ready trigger will not give a lot of improvement. According to my research, you need to delay the tag AT LEAST to the Window Loaded trigger to have more significant results.

Will I lose data if I delay a tag to fire on DOM Ready?

A little, but not as much as when the tag is delayed to Window Loaded.

But why does this loss happen at all? The more you delay the moment when the tag fires in GTM, the higher the chances are that you’ll lose miss out on some data. Why? Because if your page loads super slowly, some visitors will not wait and will leave even before any content appears on a page. In that case, the tag that fires on DOM Ready will not have a chance to fire.

So what is the potential data loss if we compare a tag that fires on Pageview vs DOM Ready? Here’s an example. I’ve set a GA tag to fire on 3 different triggers:

• Page view
• DOM Ready
• Window Loaded

All events were set as non-interaction hits. After a while here were the total event numbers from the GA reports:

As you can see in the report, there is a slight decrease in every step/delay. However, look at this data with a grain of salt.

Final words

Based on my setups, DOM Ready trigger is most often used in these two scenarios:

• When you want to send some custom data with the pageview tag but the developer pushes that custom data to the Data Layer AFTER the GTM container is loaded. If that is the case, you should delay your pageview tag (e.g. GA Page view tag) to DOM Ready event.
• When you want to access values of certain page elements (with DOM Element or Custom JS variable) and send that with a pageview tag.

If you are worried about the page performance, then consider using at least Window Loaded instead (or delay the tag even more).

Got questions? Post them below.