Does anyone here remember when in 2015 I tried to understand how DTM executes Javascript, and in what order? The article cost me days to write, but it led to a lovely, colourful illustration, and I was proud of it, a little bit.
I promised I would explore the depths of Launch in the same way, and so here comes the equivalent, for Launch.
First things first: this one is almost disappointingly simple.
All of the weird and wonderful behind-the-scenes logic that came with DTM’s Page Load Rules was replaced, in Launch, with explicit Events and Actions, and the whole setup pretty much does exactly what you’d expect.
Don’t get me wrong: that is really good!
The downside is that this article only took me like 20 minutes to write, that there is no need to make a colourful illustration, and that my friend Lukas can rightfully accuse me of not being innovative anymore.
Oh, well…
Details
Again, I made a test page. I actually made two, one that loads Launch synchronously, and one that loads it asynchronously.
Here they are. The sync page first:
<!DOCTYPE html>
<html>
<head>
<title>Launch Load Order - Simple</title>
<script>console.log("page: JS in head before loading Launch.");&lt;/script>
<script src="//assets.adobedtm.com/launch-ENf912a119f4224c6e87b91b3e712798f6.min.js"></script>
<script>console.log("page: JS in head after loading Launch.");</script>
<script src="//code.jquery.com/jquery-3.3.1.min.js"></script>
</head>
<body>
<p>This is a simple test page.</p>
<script>
console.log('page: right in the body.')
$(document).ready(function() {
console.log("page: DOM Ready.");
});
$(window).on("load", function() {
console.log("page: Window loaded.");
});
console.log("page: JS in body before pageBottom() call.");
</script>
<script type="text/javascript">_satellite.pageBottom();</script>
<script>console.log("page: JS in body after pageBottom() call.");</script>
</body>
</html>
And the async page:
<!DOCTYPE html>
<html>
<head>
<title>Launch Load Order - Simple</title>
<script>console.log("page: JS in head before loading Launch.");</script>
<script src="//assets.adobedtm.com/launch-ENf912a119f4224c6e87b91b3e712798f6.min.js" async></script>
<script>console.log("page: JS in head after loading Launch.");</script>
<script src="//code.jquery.com/jquery-3.3.1.min.js"></script>
</head>
<body>
<p>This is a simple test page.</p>
<script>
console.log('page: right in the body.')
$(document).ready(function() {
console.log("page: DOM Ready.");
});
$(window).on("load", function() {
console.log("page: Window loaded.");
});
</script>
</body>
</html>
In Launch, I built 5 Rules:
- 4 “normal” Rules that fire on “Library load (Top of Page)”, “Page Bottom”, “DOM Ready”, and “Window Loaded”, respectively, and
- 1 Rule with a “Custom Code” Event, which just calls
trigger();immediately.
I used a “Custom Code” Condition in each Rule, which logged to the Console and returned true, and added a “Custom Code” Action, which just made itself known.
The 5th Rule had a “Custom Code” Event Type. The code just printed to the Console, then immediately called trigger().
The resulting Library came with just 3 extra JS files, which contained the “Custom Code” Actions of 3 of the Rules (the ones with “DOM Ready”, “Window Loaded”, and “Custom Code” Event Types. The latter was a surprise.)
Again, I held my breath, and loaded the pages.
Here are the results:
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2019/04/190416-load-order-simple-sync.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2019/04/190416-load-order-simple-async.png)
Order
As I said above: there are no surprises in there, or almost none. And that is great!
The only little thing that I didn’t see coming was the execution of the 5th Rule.
That one is evaluated in the very beginning, even before the “Library Loaded (Top of Page)” Event Type, and the Action fires pretty late, after the “DOM Ready” event happened.
Otherwise, everything was in order.
Some Event Types must, by design, have Actions that can happen after DOM Ready (which means no document.write(), for example). This is the default behaviour in Launch.
If a Rule has an Event Type “Library Loaded” or “DOM Ready”, though, we expect that Rule to behave as it would have in DTM, namely to run immediately. And so, for Rule that have Events of these two Types, the system embeds all code directly into the Library, and executes it sync.
Actions in all other Rules will, by default, be executed async.
Stay tuned for the next article, when I take my two test pages and add an Extension into the mix.
Extensions, by design, are about scripting, and I suspect there are more interesting results to see with an Extension.
Web Analytics for Developers 
If there is going to be a follow-up with usage of Analytics, ECID and Target in async, I will probably forgive you this one 😉
LikeLike
Yes, there will be
LikeLike
Helpful stuff, Jan — I always love the way you simplify! Can you think of a use case where you would want your Analytics to run synchronously, but your Target to run asynchronously? How would you suggest handling a scenario such as this?
LikeLike
Hi Brig,
I have heard people wanting it the other way round: Target sync and Analytics async – reduces flicker, but makes page faster. Noone has ever asked me for the other way round.
Given how Launch works, sync or async is basically a decision between being able to execute Javascript right in the header and having the first Javascript execute after DOM Ready. For your use case, you would have to deploy sync, then build triggers yourself, maybe using promises, which would in turn call Rules with a Direct Call Event Type.
Cheers,
Jan
LikeLike
So your page load events happened in this order:
1. Library Loaded
2. Page Bottom
3. DOM Ready
4. Window Loaded.
I tried the same test and I got the same results.
LikeLike