Shared publicly  - 
Async script loading of 3rd party JS
It is now accepted knowledge that 3rd party JavaScript should be loaded asynchronously. There are various benefits with respect to speed and limited interference with loading the embedding page, but the main benefit is that in scenarios like a couple weeks ago when Facebook went down, a timeout of a 3rd party script tag, does not automatically take down your page as well.

The classic async embed code looks something like this (I use +1 because that is what I work on)
<script type="text/javascript">
  (function() {
    var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
    po.src = '';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);

Now, there is a new HTML5 hotness out there that is much simpler:
<script src="" async></script>

Browsers do not execute JS until all stylesheets that are referenced above it and all scripts above it in the DOM have been loaded and executed. That means that will the old-style embed code, your browser likely won't even start downloading the script until very late in the load process of a given page.

Modern browsers have look ahead parsers that start downloading resources like stylesheets and scripts long before they may be able to actually run them, essentially just scanning the HTML and looking for everything that may be useful in the future. This is where the new hotness wins big: Being a normal script tag, the pre-scanning parser can see it and start downloading the script early on.

So we want the async attribute! BUT, of course, there is a catch: IE<10 does not support it (I know, surprise, surprise). All stable IEs will simply ignore the attribute and load just fine, just like a normal script tag, but they won't get the benefit of "crash-resistance" should the 3rd party site go down. So, my general question: Would you, for your site, want to give modern browsers faster loading and have IE9 and below suffer from increased risk of downtime?
Rodney Rehm's profile photoJamund Ferguson's profile photoAgustín Amenabar's profile photoMohammad Barghamadi's profile photo
Quick question: Would it be a valid solution to use IE conditionals to use the "classic async" embed code, while maintaining the "async" attribute on the script tag for all other browsers?
Most IE browsers aren't IE10 and therefore IE9=< not a minority. The only time I would find this okay, is actually if your target is a linux/mac/mobile (non-wp7) audience.
+Mathieu Gosbee The latest stat counter global statistics shows all IE at around 30%. On the site I work on IE usage is around 10%. Just saying that the alternative to the fancy syntax isn't actually all that bad in most cases and the ease of the HTML5 syntax to me means it will be much easier to get people to actually use it.

Certainly if you're a huge site like Facebook use the fancy solution, but I was pretty bummed to not even see the HTML5 async syntax mentioned in several of the "how to make 3rd party js widgets not ruin your page" talks at fluentconf. People should be talking about this, because it's simple and useful.

It also sounds like from the main post here that the <script async> version is actually likely to be loaded faster by your browser.
I would just use a JS script loader that does what googles async snippet does. Best of both worlds, since scripts loaders are so small anyway
is this too obvious?

<!--[if lt IE 10]>
<script type="text/javascript">
  (function() {
    var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
    po.src = '';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
<!--[if gte IE 10]><!-->
<script src="" async></script>
+Scott Corgan It could be done with conditional comments. Maybe that is actually not such a bad idea, but it would one-up the ugliness scale by 1000 points.

+Peter Müller Script loaders are fine but they also suffer from the not-being able to look ahead problem.
+Rodney Rehm Not too obvious. Was just thinking of the same thing. But very ugly.
+Malte Ubl any comments on how using the defer attribute for IE might help (or not) in this case. <script async defer> ????
+Jamund Ferguson Yeah, it just changes semantics of the script tag to be loaded like it was at the end of the DOM tree. A transformation that can be otherwise achieved by placing the script tag before the closing body tag. While this may be desirable, it does not detach the script from page load and it thus just as bad in the "3rd party site is down" case as not having defer.
+Malte Ubl ugly? yes. Solving the problem 100%? yes.

I wouldn't consider the current state of the art asynchronous script loading approach "beatiful". in fact, it's butt ugly. But it gets the job (being loading a javascript resource in a non-blocking fashion) done just fine. I don't think there is a "beatiful" solution to this…
+Rodney Rehm Yeah, I like it, too. Would put it on my site. I don't really feel comfortable with recommending it for everybody, but those who know what they are doing should do this!
+Mathieu Gosbee While often a good idea, scripts at the bottom of the page are still subject to negatively impacting page load time when they time out.
+Jamund Ferguson In our case we actually only load a tiny script loader, so we want it to execute as soon as possible. Defer would delay execution while gaining few other benefits.
+Malte Ubl In my opinion you have two kinds of developers. Those who know why you need async loading, and those who don't. Those who don't, usually just copy a snippet from some integration page, without understanding what it is they're copying. And those who do understand what's going on, surely quickly realise the benefit of the butt ugly CC+script approach, once they've understood what a browser's pre-parser actually does.

That said, I don't understand why you'd feel uncomfortable putting that on say

Imho CC+script is the next logical step to take for async script loading, because it allows modern browsers to leverage their pre-parsers while "degrading" nicely for the oldIE folks.

According to we might want to think up something for Opera, though.
+Stephan Hoyer Please expand. Why? (Taking into consideration the rest of the discussion)
For common, fast, economical optimizations this works great, of course you can always micro-optimize.
Great post, thanks!
Add a comment...