Adobe Tech Blog
Published in

Adobe Tech Blog

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:

<script src="example.js"></script>

By default, as the browser parses the document and reaches this line, it starts to fetch the JavaScript file from the server. It will then wait until the file is returned, at which point it parses and executes the JavaScript file. Only then does it continue parsing the rest of the HTML document.

If the parser comes across your script tag before rendering visible content, your users will be stuck waiting for that moment of satisfaction. If the JavaScript file being loaded isn’t absolutely necessary to show content to your users, you are unnecessarily nudging your users to look elsewhere. Website performance benchmark tools like Google PageSpeed or Lighthouse will often flag synchronously loaded scripts for this reason.

Synchronous example

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 script tag loads a JavaScript file that is 844 KB raw or 175 KB gzipped (the file is transferred over the internet gzipped, which means it’s compressed to save space and time).

By using the performance tools in Google Chrome, we can see that the “first paint” is delayed until after our JavaScript file is loaded and executed. First paint is the moment initial content is shown to the user and is a key website performance benchmark. The total time between when the page begins to load and first paint is 571 milliseconds. Nearly all of that time was waiting for the JavaScript file to download and execute.

Performance while loading a script synchronously

Asynchronous example

Now let’s try loading in the JavaScript file asynchronously. To do this, we’ll add an async attribute to the script tag as follows:

<script src="example.js" async></script>

This tells the browser to begin loading the example.js JavaScript file, and instead of waiting around for the file to be loaded and executed, it should immediately continue to parse and render the rest of the document.

Let’s see how this affects performance in our example scenario.

Performance while loading a script asynchronously

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?

Yes, there can be drawbacks. Remember, the whole goal was to get content to our users faster. We can achieve that by asynchronously loading the JavaScript, but as a consequence, the JavaScript will execute after content has been displayed to the user. This isn’t typically a problem, but requires careful consideration under certain circumstances.

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="//"></script>

to this:

<script src="//" 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 body tag:

<script type="text/javascript">_satellite.pageBottom();</script>

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.

Installation instructions

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.




News, updates, and thoughts related to Adobe, developers, and technology.

Recommended from Medium

Add share application feature in React Native Expo App

How to set or change line endings of a Text File in Node.JS

Touch Bar Instagram followers count — UPDATE 2020

How to understand the keyword this and context in JavaScript

JavaScript For Fun: Some Tricky Tropics In Interview

10 Reasons: Why to consider React Native while building an application from scratch [Detailed…

What i learnt after using Nuxt.js for 3 months

React Recoil 0.1.2 — Recoilize is here for you

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aaron Hardy

Aaron Hardy

I am a software engineer at Adobe working on the Adobe Experience Platform Web SDK. I am a fan of documentaries, podcasts, and bikes.

More from Medium

Powering Adobe MAX with App Builder and I/O Runtime

Chimera card collection built with Adobe App Builder surfaces personalized Adobe MAX content tiles based on user activities and recommendations, across relevant pages on

Securing TrueCar, Miles Apart

Content Management Systems: 10 tips for choosing the right one — part 2

Developing High-performance Virtual Teams!