{"id":91556,"date":"2025-02-16T11:29:44","date_gmt":"2025-02-16T11:29:44","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/the-custom-html-tag-guide-for-google-tag-manager\/"},"modified":"2025-02-16T11:29:44","modified_gmt":"2025-02-16T11:29:44","slug":"the-custom-html-tag-guide-for-google-tag-manager","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=91556","title":{"rendered":"The Custom HTML Tag Guide For Google Tag Manager"},"content":{"rendered":"


\n<\/p>\n

and passed for injection.<\/p>\n
  • Upon injection, each element is added as the last child of the document.body<\/code> element.<\/li>\n

    There are some nuances to this process, such as how Google Tag Manager handles the onHtmlSuccess<\/code> and onHtmlFailure<\/code> callbacks in tag sequencing<\/a>, and how <\/code> elements are stripped of all custom attributes before injection. But overall, this is the process.<\/p>\n

    Now, what this essentially means is that anything you type into a Custom HTML tag is added to the end of body<\/code>, whatever that is at the time of injection. Typically, this translates to: \u201cThe bottom of the page\u201d<\/strong>, but this is not a given with today\u2019s fluid layouts.<\/p>\n

    \n

    <\/p>\n

    \"Injected<\/p>\n

    <\/a><\/p>\n<\/div>\n

    One extremely important<\/strong> thing to keep in mind is that when you add a new element to the page you force a reflow<\/strong> of the content. Basically, the browser has to calculate again dimensions, positioning, layouts, and attributes of elements preceding, surrounding, and nested within the injected element.<\/p>\n

    This is not a painless operation. Each element you add compounds to the problem, and on single-page apps<\/strong> which might not reset the DOM between transitions, you could end up with hundreds of injected elements on the page, each hurting the performance in exponential increments.<\/p>\n

    We\u2019ll get to this in the summary, but just to foreshadow the conclusion:<\/p>\n

    Avoid using Custom HTML tags unless it\u2019s absolutely necessary<\/strong>.<\/p>\n

    Yes, I do recognize the irony of such a disclaimer on this particular article.<\/p>\n

    Why use Custom HTML tags? Why use a tag management solution for element injection?<\/p>\n

    Great question! And one I don\u2019t have a hard-and-fast answer for. I\u2019d say an abundance of Custom HTML tags in a container is symptomatic of one (or more) of the following things:<\/p>\n

      \n
    1. You have use cases far too complicated<\/strong> for GTM\u2019s native tags or custom templates<\/a> to handle.<\/li>\n
    2. You have too little knowledge<\/strong> about GTM (or JavaScript) to know that some of your custom HTML tags could be replaced with native tags or custom templates.<\/li>\n
    3. You have an inflexible organization<\/strong>, where getting the web developers to add your customizations directly to the page templates (or other site code) is not an option.<\/li>\n
    4. You\u2019ve found a cool thing<\/strong> online, and you want to quickly proof-of-concept it before passing it to the web developers for proper implementation.<\/li>\n
    5. You are drunk with power<\/strong> over what you can do on your site with Google Tag Manager, and no bald dude from Finland is going to stop you from doing it.<\/li>\n<\/ol>\n

      It\u2019s your container – you are of course free to use it however you wish. But if scenarios (2) and (3) ring a bell, I strongly urge you to seek change to the status quo. Being ignorant about the intricacies of GTM and JavaScript can be counter-productive to the beneficial effects that these technologies enable. Similarly, working against the constraints set by your organization will cause more friction in the long run, and can lead to inflamed communication structures, a crappy site, and unstable data collection.<\/p>\n

      Having said all that, let\u2019s explore some of the scenarios where you might be tempted to use a Custom HTML tag!<\/p>\n

      Adding an element to a particular position on the page<\/h3>\n

      The downside of the Custom HTML tag is that it injects the element to the end of . But what use is that? If the element is a visual component (something that should be shown on the screen), then most likely the end of is not<\/strong> where you want it to end up in.<\/p>\n

      To rectify this, you need to use JavaScript<\/strong> and its DOM manipulation methods<\/a>.<\/p>\n

      The trick is to find some element that\u2019s already<\/em> on the page, and then position the new element relative<\/em> to that.<\/p>\n

      For example, let\u2019s say I want to add a little subtitle<\/em> to this current page, so that it ends up looking like this:<\/p>\n

      \n

      <\/p>\n

      \"Subtitle<\/p>\n

      <\/a><\/p>\n<\/div>\n

      Now, if I created a Custom HTML tag with just this:<\/p>\n

      \n
      h3>It's really cool - I promise!h3<\/span>><\/code><\/pre>\n<\/div>\n
      The element would be added to the end of  and wouldn\u2019t look very good.<\/p>\n
      So, instead, I need to create a new element with JavaScript<\/strong>, and then position this new element relative to the title of the page<\/strong>.<\/p>\n
      \n
      script>\n  (function<\/span>() {\n    \/\/ Create a new H3 element\n<\/span>    var<\/span> h3 = document<\/span>.createElement('h3'<\/span>);\n    \n    \/\/ Add the text content\n<\/span>    h3.innerText = \"It's really cool - I promise!\"<\/span>;\n    \n    \/\/ Get the reference to the current heading\n<\/span>    var<\/span> title = document<\/span>.querySelector('h1'<\/span>);\n    \n    \/\/ Inject the new element right after the H1\n<\/span>    if<\/span> (title) {\n      title.parentElement.insertBefore(h3, title.nextSibling);\n    }\n  })();\nscript<\/span>><\/code><\/pre>\n<\/div>\n
      The end result? You can see it in the screenshot above.<\/p>\n
      There\u2019s a subtle irony here – you are using Custom HTML tag to create an element<\/strong> (the <\/code>) that creates an element<\/strong> (the <\/p>\n<\/code>). Yes, it would be cool if you could specify in a Custom HTML tag to where the element is inserted. Actually, it would be even cooler if there were a custom template<\/strong> that allows you to create elements with positioning options. That way you wouldn\u2019t need the invasive end-of-body script injection at all!<\/p>\n
      But I digress.<\/p>\n
      Adding a script \u201cas high up\u201d in  as possible<\/h3>\n
      This is somewhat related to the previous scenario, but it deserves its own treatment because of how often the scenario emerges.<\/p>\n
      Sometimes, a vendor instructs you to \u201cPlace our script as HIGH UP in  as possible\u201d<\/strong>.<\/p>\n
      This is instructed because the vendor wants their script to fire as soon as possible<\/strong> on the page. The higher an element in , the sooner the browser parses it as part of the page render.<\/p>\n
      \n
          <\/p>\n
          \"Fire<\/p>\n
          <\/a><\/p>\n<\/div>\n
      However, this benefit is largely lost<\/strong> when using Google Tag Manager. When the Google Tag Manager library has loaded, it\u2019s typical that the parsing of  has already finished, and the browser is well into rendering the . Because of this, trying to inject a script as high up in  as possible doesn\u2019t make any sense, and is actually detrimental<\/strong> to the intended end result.<\/p>\n
      Why? Because when you create a Custom HTML tag that then creates an element and injects it into , the browser first needs to inject the Custom HTML tag (performance hit), and then it needs to create the new element (another performance hit), and finally it needs to inject the new element into  (performance hit).<\/p>\n
      \n
          <\/p>\n
          \"Proper<\/p>\n
          <\/a><\/p>\n<\/div>\n
      Instead – all you need to do is add the <\/code> directly to the Custom HTML tag. This way it will get inserted to the end of , and the browser will execute it as soon as possible.<\/p>\n
      Load vendor JavaScript<\/h3>\n
      In fact, let\u2019s continue the thought experiment from the previous scenario. Let\u2019s say you do<\/strong> have a vendor whose JavaScript you want to load on the site, and you\u2019ve established that all you need to do is add the <\/code> element to the page with a Custom HTML tag.<\/p>\n
      My friend. Do not use a Custom HTML tag at all<\/strong>.<\/p>\n
      Instead, create a custom tag template<\/a> that uses the injectScript<\/code> API<\/a> to load the library.<\/p>\n
      Custom templates are optimized to inject and load the JavaScript, and they introduce a permissions<\/a> and policies<\/a> model for safe(r) injection.<\/p>\n
      \n
          <\/p>\n
          \"Custom<\/p>\n
          <\/a><\/p>\n<\/div>\n
      Going forward, this will be the best way to proceed with <\/code> injection. It won\u2019t help you with some of the other scenarios, as the JavaScript sandbox of templates is extremely restricting. So if you want to add custom event listeners<\/a>, for example, you\u2019ll still need ye olde Custom HTML tag.<\/p>\n
      Modify user experience<\/h3>\n
      One of the things you might be tempted to do with Google Tag Manager\u2019s Custom HTML tags is modify the user experience<\/strong>. This could be adding something like a cookie banner<\/strong>, or maybe editing the styles<\/strong> on the page, or perhaps adding an