Asynchronously Loading the Launch Runtime Library
We’ve all been there — clicking through search engine results one after the other looking for the right cat gif to send our coworkers. If any website takes more than two shakes of a lamb’s tail to load, we’re out. Why wait for a slow website when we can bounce to the next website with the click of a button?
With Adobe Experience Platform Launch, we understand that we play a role in how long it takes for your website content to load. We prefer not to be a bottleneck. To that end, we now support the ability to load our runtime library asynchronously.
How can asynchronicity improve performance?
We’re glad you asked. Traditionally, to load a script on our website, we might have a
script tag in our HTML that looks something like this:
If the parser comes across your
For illustration purposes, I’ve set up a fairly bare bones webpage that contains a
script tag like the one mentioned above. The
script tag is placed within the
head of the document. The
async attribute to the
script tag as follows:
<script src="example.js" async></script>
This tells the browser to begin loading the
Let’s see how this affects performance in our example scenario.
The total time between when the page begins to load and first paint is now 19 milliseconds. We’ve managed to shave off more than a half second to first paint. Less time waiting for content → faster user engagement → lower abandonment → more success!
Are there drawbacks?
As an example, when using products like Adobe Target, personalized content is loaded dynamically at runtime. Typically, we try to hide part or all of the body content until the personalized content is loaded. If we don’t, default content will be shown to the user and then moments later it will be swapped out for the personalized content. This is known as “flicker” and is considered undesirable for the user experience.
Assuming we install the Adobe Target extension through Launch, and we decide to load the Launch runtime asynchronously, the Adobe Target extension code will not be executed early enough to hide default content before it is shown to the user. Without taking extra precautions, users would experience flicker when Target later replaces the default content with personalized content. Similar behavior can be expected with other testing and optimization tools; this is not specific to Adobe Target.
You can still load the Launch runtime library asynchronously while avoiding this flicker by embedding a small, inline script within your HTML that runs before content is shown. This inline script can’t be deployed through Launch and will require manually editing your HTML. Optionally, you can continue to load Launch synchronously, recognizing you may miss out on some performance benefits.
Another consideration is that Launch has always provided a Page Bottom event type that allows users to fire a rule at the precise moment the bottom of the
body tag is reached by the browser parser. Because the Launch runtime will likely finish loading after the page bottom has been reached, the Page Bottom event type may not fire associated rules at the time you may expect. For this reason, when loading Launch asynchronously, we suggest not using the Page Bottom event type, but instead consider the Library Loaded, DOM Ready, Window Loaded, or other event types.
How do I load Launch asynchronously
Above, we learned how to add an
async attribute to the
script tag to make the script load asynchronously. For the Launch embed code, that means changing this:
<script src="//assets.adobedtm.com/launch-EN1a3807879cfd4acdc492427deca6c74e.min.js" async></script>
Note that the URL you use in your script tag will be different than this example.
Next, you’ll remove the Page Bottom code at the bottom of your
This is the code that tells Launch that the browser parser has reached the bottom of the page. Since Launch will likely not have loaded and executed before this time, calling
_satellite.pageBottom() would result in an error. As mentioned previously, a consequence of this is that the Page Bottom event type may not behave as expected.
For your convenience, we’ve illustrated these implementation changes in the Launch user interface. When configuring an environment, you will receive instruction on how to install Launch on your website. A toggle is provided so you can easily switch between loading the library synchronously or asynchronously. The code snippets will update accordingly. Note that this has no effect on the content of the file being loaded — only on how it is loaded.
Have you seen a performance boost loading Launch asynchronously? Have you run into problems other users should be aware of? If so, we’d love to hear about it in the comments below.