Sometime in the past (circa 2009):
The Tubes: “pst”
Me: “Hmm? What’s that”
The Tubes: “It’s me. The intertubes. The network of copper, fiber, and – “
Me: “Yeah yeah, I know all about you. I’ve been monitoring you for quite a number of years.”
The Tubes: “Well… that’s kind of creepy. I was going to give you a heads-up, but now I don’t know if I should be talking to you…”
Me: “No no, it’s cool. What’s up?”
The Tubes: “The W3C is going to make a change to the <script> tag. You should check it out.”
Me: “Interesting. What should I be looking for?”
The Tubes: “Reach out to this guy called ‘async’. Okay, I’ve got to go, someone wants to download 320GB of LOLCats pictures…”
Here’s a quick summary of the facts:
- Async was introduced in the W3C’s HTML5 specification and is currently in the working draft (http://www.w3.org/TR/html5/).
- Async is an attribute of the <script> tag.
- Async is intended to replace the defer attribute but for legacy reasons, both attributes can be set on the same element (defer has been around a lot longer).
- Changing the Async or defer attributes dynamically has no direct effect (they only impact the browser at specific times during the page rendering process).
- Async will have no effect on non-compliant browsers (i.e. older browser versions will just ignore and consider it a custom user attribute).
- Async (and defer) should not be specified if the src attribute is not present or if it’s not set to a valid URL (i.e. if your script’s code is in-line on the HTML document).
So why is async important and how does it benefit analytics? The technical answer is that it allows for true non-blocking execution of code during page load [very, very important!]. The non-technical answer is that we can insert our tagging code at the top of pages, and it’ll run immediately without holding up page-loads. This is pretty important. All the big pixel-trackers (Webtrends, Adobe SiteCatalyst, and Google Analytics) recommended inserting tags at the tail of the <body> tag, so running the code that makes the pixel request [or beacon as some call it] doesn’t hold up or slow down page-load times; however, that can be a pain for different templating/view structures that require customization to control where the footers are rendered.
Many people don’t know that async is a direct descendant (from a design perspective) of the defer attribute. Defer was introduced in HTML4 but does not make the <script> element asynchronous. Instead, it allows the code to be downloaded without being interpreted (remember, all scripts in HTML are interpreted, not compiled) until the page has finished parsing.
It’s important to remember amongst all the excitement that the async attribute won’t be backwards compatible. As I mentioned above, it’s part of the W3C’s HTML5 specification. Over the past two years, we’ve seen a lot of companies/organizations who have tried to set a standard ahead of the W3C (such as Microsoft) in an attempt to circumvent the wait times associated with the lengthy approval process that comes with W3C’s standards release process. As such, there is a chance that different browsers claiming to be HTML5 ready may have different implementations or interpretations of this attribute.
This doesn’t mean you shouldn’t use the async attribute – but as things are changing fairly regularly, it’s a good idea to keep tabs on your (or your clients’) supported browsers and how they interpret the tag from a technical perspective.