12 October, 2022

Speeding Up Async Snippets

Q: What is an async snippet?

Async snippets are a JavaScript design pattern largely employed by third parties to inject subsequent scripts in an asynchronous manner. Async snippets are a legacy implementation designed to sidestep a lack of support for the HTML async attribute for script elements. Compared to the async attribute, async snippets are considered an anti-pattern and should be avoided.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…

Table of Contents

What Is an Async Snippet?
Legacy async Support
What’s Wrong With the Polyfill?
1. The Preload Scanner
The New Syntax
When We Can’t Avoid Async Snippets
1. Dynamic Script Locations
2. Injecting Into a Page You Don’t Control
Takeaways

If you’ve been a web developer for any reasonable amount of time, you’ve more likely than not come across an async snippet before. At its simplest, it looks a little like this:

<script>
  var script = document.createElement('script');
  script.src = 'https://third-party.io/bundle.min.js';
  document.head.appendChild(script);
</script>

Here, we…

create a <script> element…
whose src attribute is https://third-party.io/bundle.min.js…
and append it to the <head>.

The first thing I find most surprising is that the majority of developers I encounter do not know how this works, what it does, or why we do it. Let’s start there.

What Is an Async Snippet?

Snippets like these are usually employed by third parties for you to copy/paste into your HTML—usually, though not always, into the <head>. The reason they give us this cumbersome snippet, and not a much more succinct <script src="">, is purely historical: async snippets are a legacy performance hack.

When requesting JavaScript files from the DOM, they can be either blocking or non-blocking. Generally speaking, blocking files are worse for performance, especially when hosted on someone else’s origin. Async snippets inject files dynamically so as to make them asynchronous, or non-blocking, and therefore faster.

But what is it about this snippet that actually makes the file asynchronous? There’s no async attribute in sight, and the code itself isn’t doing anything special: it’s just injecting a script that resolves to a regular, blocking <script> tag in the DOM:

  ...
  <script src="https://third-party.io/bundle.min.js"></script>
</head>

How is this any different to just loading the file normally? What have we done that makes this asynchronous? Where is the magic?!

Well, the answer is nothing. We didn’t do a thing. It’s the spec which dictates that any scripts injected dynamically should be treated as asynchronous. Simply by inserting the script with a script, we’ve automatically opted into a standard browser behaviour. That’s really the extent of the whole technique.

But that begs the question… can’t we just use the async attribute?

As a bit of additional trivia, this means that adding script.async='async' is redundant—don’t bother with that. Interestingly, adding script.defer=defer does work, but again, you don’t need an async snippet to achieve that result—just use a regular <script src="" defer>.

Legacy `async` Support

It wasn’t until 2015 (admittedly, that is seven years ago now…) that all browsers supported the async attribute. For all major browsers, that date was 2011—over ten years ago. So, in order to work around it, third party vendors employed async snippets. Async snippets are, at their most basic, a polyfill.

Nowadays, however, we should be going straight into using <script src="" async>. Unless you have to support browsers in the realm of IE9, Opera 12, or Opera Mini, you do not need an async snippet (unless you do…).

What’s Wrong With the Polyfill?

If the polyfill works, what’s the benefit of moving to the async attribute? Sure, using something more modern feels nicer, but if they’re functionally identical, is it better?

Well, unfortunately, this performance polyfill is bad for performance.

For all the resulting script is asynchronous, the <script> block that creates it is fully synchronous, which means that the discovery of the script is governed by any and all synchronous work that happens before it, whether that’s other synchronous JS, HTML, or even CSS. Effectively, we’ve hidden the file from the browser until the very last moment, which means we’re completely failing to take advantage of one of the browser’s most elegant internals… the Preload Scanner.

The Preload Scanner

All major browsers contain an inert, secondary parser called the Preload Scanner. It is the job of the Preload Scanner to look ahead of the primary parser and asynchronously download any subresources it may find: images, stylesheets, scripts, and more. It does this in parallel to the primary parser’s work parsing and constructing the DOM.

Because the Preload Scanner is inert, it doesn’t run any JavaScript. In fact, for the most part, it only really looks out for tokenisable src and href attributes defined later in the HTML. Because it doesn’t run any JavaScript, the Preload Scanner is unable to uncover the reference to the script contained within our async snippet. This leaves the script completely hidden from view and thus unable to be fetched in parallel with other resources. Take the following waterfall:

Here we can clearly see that the browser doesn’t discover the reference to the script (3) until the moment it has finished dealing with the CSS (2). This is because synchronous CSS blocks the execution of any subsequent synchronous JS, and remember, our async snippet itself is fully synchronous.

The vertical purple line is a performance.mark() which marks the point at which the script actually executed. We therefore see a complete lack of parallelisation, and an execution timestamp of 3,127ms.

To read more about the Preload Scanner, head to Andy Davies’ How the Browser Pre-loader Makes Pages Load Faster.

The New Syntax

There are few different ways to rewrite your async snippets now. For the simplest case, for example:

<script>
  var script = document.createElement('script');
  script.src = 'https://third-party.io/bundle.min.js';
  document.head.appendChild(script);
</script>

…we can literally just swap this out for the following in the same location or later in your HTML:

<script src="https://third-party.io/bundle.min.js" async></script>

These are functionally identical.

If you’re feeling nervous about completely replacing your async snippet, or the async snippet contains config variables, then you can replace this:

<script>
  var user_id     = 'USR-135-6911-7';
  var experiments = true;
  var prod        = true;
  var script      = document.createElement('script');
  script.src      = 'https://third-party.io/bundle.min.js?user=' + user_id;
  document.head.appendChild(script);
</script>

…with this:

<script>
  var user_id     = 'USR-135-6911-7';
  var experiments = true;
  var prod        = true;
</script>
<script src="https://third-party.io/bundle.min.js?user=USR-135-6911-7" async></script>

This works because, even though the <script src="" async> is asynchronous, the <script> block before it is synchronous, and is therefore guaranteed to run first, correctly initialising the config variables.

async doesn’t mean run as soon as you’re ready, it means run as soon as you’re ready on or after you’ve been declared. Any synchronous work defined before an async script will always execute first.

Now we can see the Preload Scanner in action: complete parallelisation of our requests, and a JS execution timestamp of 2,340ms.

Interestingly, the script itself took 297ms longer to download with this newer syntax, but still executed 787ms sooner! This is the power of the Preload Scanner.

When We Can’t Avoid Async Snippets

There are a couple of times when we can’t avoid async snippets, and therefore can’t really speed them up.

Dynamic Script Locations

Most notably would be when the URL for the script itself needs to be dynamic, for example, if we needed to pass the current page’s URL into the filepath itself:

<script>
  var script = document.createElement('script');
  var url    = document.URL;
  script.src = 'https://third-party.io/bundle.min.js&URL=' + url;
  document.head.appendChild(script);
</script>

In this instance, the async snippet is less about working around a performance issue, and more about a dynamism issue. The only optimisation I would recommend here—if the third party is important enough—is to complement the snippet with a preconnect for the origin in question:

<link rel=preconnect href="https://third-party.io">

<script>
  var script = document.createElement('script');
  var url    = document.URL;
  script.src = 'https://third-party.io/bundle.min.js&URL=' + url;
  document.head.appendChild(script);
</script>

Injecting Into a Page You Don’t Control

The second most probable need for an async snippet is if you are a third party injecting a fourth party into someone else’s DOM. In this instance, the async snippet is less about working around a performance issue, and more about an access issue. There is no performance enhancement that I would recommend here. Never preconnect a fourth, fifth, sixth party.

Takeaways

There are two main things I would like people to get from this post:

Specifically, that async snippets are almost always an anti-pattern. If you’re utilising them, try move yourself onto a new syntax. If you’re responsible for one, try updating your service and documentation to use a new syntax.
Generally, don’t work against the grain. While it might feel like we’re doing the right thing, not knowing the bigger picture may leave us working against ourselves and actually making things worse.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…

Hire me

By Harry Roberts

Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.

Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.