Expand my Community achievements bar.

SOLVED

Load Order for Rules :: DTM vs. Launch

Avatar

Level 10

When working with marketing pixels, my site performance guy and I use the Load Order for Rules document to make sure we are putting the pixel in the least disruptive location on the page (while still getting the pixel what it needs).

In the Launch Rules, I see the 4 page load phases (see screen shot 1 below). But, when I go to set-up my pixel in the Action Configuration, I only see JavaScript and HTML (see screen shot 2 below). In DTM, I am able to choose Sequential HTML, Sequential JavaScript, Non-Sequential HTML, and Non-Sequential JavaScript (see screen shot 3 below).

Screen Shot 1 :: 4 Page Load Phases in Launch

1279620_pastedImage_3.png

Screen Shot 2 :: Only 2 Options in Launch (JavaScript and HTML)

1279628_pastedImage_5.png

Screen Shot 3 :: 4 Options in DTM

1279629_pastedImage_6.png

1 Accepted Solution

Avatar

Correct answer by
Employee

SarahEOwen​​ I don't have any problem talking about load order in the meeting but I'll defer to thebenrobb since he's the PM. It sounds like you're interested in some of the deeper details though. I'm happy to dive deeper here so you can have something written that your group can stew on. Some of this is from memory, so if it's inaccurate, I apologize.

In DTM:

  • Rules with page bottom or page top event:
    • Sequential JavaScript:
      • document.write would be used to load an external script in a blocking fashion. This means the browser will download and execute the external script before continuing to parse the rest of the document. Note that, for users with low bandwidth, Chrome recently started blocking attempts to document.write script tags that load external scripts. Avoiding this was one of the goals in Launch. If the rule has two sequential JavaScripts, the first one will load and execute before the second one begins to load and execute.
    • Non-sequential JavaScript:
      • A script element would be generated and added to the document. When dynamically created script elements are created and added to the document, the browser loads the script asynchronously (in a non-blocking fashion). If the rule has two non-sequential JavaScripts, they will be loaded and executed in any order. One possible result is that script A begins to load, script B begins to load, script B finishes loading and executes, then script A finishes loading and executes.
    • Sequential HTML
      • document.write would be used to inject the HTML into the page. The custom HTML content is contained within the main DTM library, so it will not make an additional request to the server for the custom HTML content.
    • Non-sequential HTML
      • An iframe would be created and added to the document. The custom HTML would be asynchronously loaded into the iframe.
  • Rules with any other event:
    • Sequential JavaScript:
      • A script element would be generated and added to the document. When dynamically created script elements are created and added to the document, the browser loads the script asynchronously (in a non-blocking fashion). Even though they are loading asynchronously, if the rule has two non-sequential JavaScripts, DTM enforces that the first will start loading, finish loading, and execute before the second starts loading.
    • Non-sequential JavaScript:
      • A script element would be generated and added to the document. When dynamically created script elements are created and added to the document, the browser loads the script asynchronously (in a non-blocking fashion). If the rule has two non-sequential JavaScripts, they will be loaded and executed in any order. One possible result is that script A begins to load, script B begins to load, script B finishes loading and executes, then script A finishes loading and executes.
    • Sequential HTML
      • Not available.
    • Non-sequential HTML
      • An iframe would be created and added to the document. The custom HTML would be asynchronously loaded into the iframe.

In Launch:

  • Rules with page bottom or page top event:
    • Javascript:
      • The JavaScript will be embedded in the main Launch library. The custom script is wrapped in a script tag and written to the document using document.write. If the rule has multiple custom scripts, they're written in order.
    • HTML:
      • The HTML will be embedded in the main Launch library. document.write is used to write the HTML to the document.  If the rule has multiple custom scripts, they're written in order.
  • Rules with any other event:
    • JavaScript
      • The JavaScript is loaded from the server as regular text, wrapped in a script tag, and added to the document using Postscribe. If the rule has multiple JavaScript custom scripts, they will be loaded in parallel from the server, but executed in the same order that was configured in the rule.
    • HTML
      • The HTML is loaded from the server and added to the document using Postscribe. If the rule has multiple custom HTML scripts, they will be loaded in parallel from the server, but executed in the same order that was configured in the rule.

A couple notable items:

You can now use document.write within your custom scripts regardless of the events configured for the rule. In DTM, document.write inside custom scripts would only work on page top or page bottom rules.

You can now order different custom code types amongst each other. For example, you can now have a JavaScript custom code action, then an HTML custom code action, then a JavaScript custom code action. Launch will ensure that they are executed in that order. This wasn't the case in DTM.

I hope that helps!

View solution in original post

9 Replies

Avatar

Employee

Hi Sarah,

In Launch, when a rule fires, the "custom action" scripts in the rule are loaded as quickly as possible in parallel, but they are executed in the order you've set within the rule, even if they finish loading out of order.  In the case of rules that use the page top or page bottom event, the "custom action" scripts are actually included in the main Launch library instead of being loaded from the server through separate requests. They will always be executed in the order you've indicated in the rule.

Avatar

Level 5

We used e.g the sequential html to load css directly into the DOM. Non-sequntial always opens an iFrame for this.

How will this be handled in Launch?

Avatar

Level 10

HI thebenrobb​ and Aaronius9er9er​  -

In the 8/22 or 8/29 meeting, can we talk about the difference between DTM Load Order and what Launch is doing?

I want to make sure I convey to my site performance guy what differences he may see - especially with the ubiquitous marketing pixels.

Thanks -

Sarah

FYI I would also mention Ambria but I don't see/know her @ handle

Avatar

Employee

Till, we no longer use iframes to load custom code. You can use the custom code action to load css directly into the DOM. It also doesn't matter which event types are used in your rule.

Avatar

Correct answer by
Employee

SarahEOwen​​ I don't have any problem talking about load order in the meeting but I'll defer to thebenrobb since he's the PM. It sounds like you're interested in some of the deeper details though. I'm happy to dive deeper here so you can have something written that your group can stew on. Some of this is from memory, so if it's inaccurate, I apologize.

In DTM:

  • Rules with page bottom or page top event:
    • Sequential JavaScript:
      • document.write would be used to load an external script in a blocking fashion. This means the browser will download and execute the external script before continuing to parse the rest of the document. Note that, for users with low bandwidth, Chrome recently started blocking attempts to document.write script tags that load external scripts. Avoiding this was one of the goals in Launch. If the rule has two sequential JavaScripts, the first one will load and execute before the second one begins to load and execute.
    • Non-sequential JavaScript:
      • A script element would be generated and added to the document. When dynamically created script elements are created and added to the document, the browser loads the script asynchronously (in a non-blocking fashion). If the rule has two non-sequential JavaScripts, they will be loaded and executed in any order. One possible result is that script A begins to load, script B begins to load, script B finishes loading and executes, then script A finishes loading and executes.
    • Sequential HTML
      • document.write would be used to inject the HTML into the page. The custom HTML content is contained within the main DTM library, so it will not make an additional request to the server for the custom HTML content.
    • Non-sequential HTML
      • An iframe would be created and added to the document. The custom HTML would be asynchronously loaded into the iframe.
  • Rules with any other event:
    • Sequential JavaScript:
      • A script element would be generated and added to the document. When dynamically created script elements are created and added to the document, the browser loads the script asynchronously (in a non-blocking fashion). Even though they are loading asynchronously, if the rule has two non-sequential JavaScripts, DTM enforces that the first will start loading, finish loading, and execute before the second starts loading.
    • Non-sequential JavaScript:
      • A script element would be generated and added to the document. When dynamically created script elements are created and added to the document, the browser loads the script asynchronously (in a non-blocking fashion). If the rule has two non-sequential JavaScripts, they will be loaded and executed in any order. One possible result is that script A begins to load, script B begins to load, script B finishes loading and executes, then script A finishes loading and executes.
    • Sequential HTML
      • Not available.
    • Non-sequential HTML
      • An iframe would be created and added to the document. The custom HTML would be asynchronously loaded into the iframe.

In Launch:

  • Rules with page bottom or page top event:
    • Javascript:
      • The JavaScript will be embedded in the main Launch library. The custom script is wrapped in a script tag and written to the document using document.write. If the rule has multiple custom scripts, they're written in order.
    • HTML:
      • The HTML will be embedded in the main Launch library. document.write is used to write the HTML to the document.  If the rule has multiple custom scripts, they're written in order.
  • Rules with any other event:
    • JavaScript
      • The JavaScript is loaded from the server as regular text, wrapped in a script tag, and added to the document using Postscribe. If the rule has multiple JavaScript custom scripts, they will be loaded in parallel from the server, but executed in the same order that was configured in the rule.
    • HTML
      • The HTML is loaded from the server and added to the document using Postscribe. If the rule has multiple custom HTML scripts, they will be loaded in parallel from the server, but executed in the same order that was configured in the rule.

A couple notable items:

You can now use document.write within your custom scripts regardless of the events configured for the rule. In DTM, document.write inside custom scripts would only work on page top or page bottom rules.

You can now order different custom code types amongst each other. For example, you can now have a JavaScript custom code action, then an HTML custom code action, then a JavaScript custom code action. Launch will ensure that they are executed in that order. This wasn't the case in DTM.

I hope that helps!

Avatar

Employee

SarahEOwen​ I don't mind talking about it in the 8/29 meeting (next office hours), but I won't be able to say anything that Aaronius9er9er9er​ didn't just say much better =)

Avatar

Level 10

Hi Aaronius9er9er​ and thebenrobb​ -

Thanks for the write-up! I've printed it off to read over it - I'll follow up with any questions.

THANKS!

Sarah

Avatar

Level 5

wow good to know. Thanks for the information.

Avatar

Level 10

Hi Aaronius9er9er -

Just got out of a meeting with the developers and the site performance guy. We really appreciate your detailed explanation and the link to postscribe on github.

Based on this info, we are going to try moving toward using DOM Ready instead of Page Bottom to take advantage of the postscribe functionality.

At this time, we do not have any follow-up questions.

Thanks -

Sarah