Beware async JavaScript loading: the next big usability fail

By | January 27, 2012
Not sure if moving JavaScript into async is a good or a bad idea. Probably both, and probably more of the latter as web development trends continue in the way they currently go. Let me explain.

Problem: JavaScript makes your site slow. According to the performance study below, on average 31% slower.

The proposed solution: Using async loading (i.e. display the page first, and load the javascript after).

Why that's not a good idea: For small applications, this is fine. Things seem to load fast and no one notices anything. But for larger web applications, this is a recipie for disaster. Loading increasingly means not just that something shows up on the page, it means that the user can start to interact with key functionality. Already, you may notice some of these characteristic traits on various 'heavy' websites:
1) Certain widgets sit there with a loading symbol for a long time. You get annoyed and then open the widgets directly.
2) You log onto G+ (or Facebook, or whatever) to post something, and then click on the box to type in something to post. Then you wait for 30 seconds (okay, exaggerating… but today it was 15-20 seconds) before you can actually type something there.

… these types of behaviour are due to the so-called async loading technique, in which the actual JavaScript allowing for the user interaction (clicking the post box, retrieving widget information) is executed after the page loads. Putting a lot of behaviour into async loading causes dramatic delays and frustration for your end user. As a result, I'd recommend a mix of async and non-async behaviour in order to get an optimal tradeoff between site loading and user expectations, especially for JavaScript-heavy sites: pre-load key functions that users are likely to click on most of the time (e.g. post), and post-load functions that they are less likely to click on (e.g. stuff in the drop-down arrow). You're going to only annoy your customers if you do otherwise.

JavaScript Performance
Last night I spoke at the San Francisco JavaScript Meetup. I gave a brand new talk called JavaScript Performance that focuses on script loading and async snippets. The snippet example I chose was the Google Analytics async snippet. The script-loading part of that snippet is only six lines, but a lot of thought and testing went into it. It’s a great prototype to use if you’re creating your own async snippet. I’ll tweet if/when the video of my talk…

2 thoughts on “Beware async JavaScript loading: the next big usability fail

  1. Sophie Wrobel

    +Poelinca Dorin you're right, there are good reasons to use async loading (and it makes a lot of sense to do so too). There are however large apps in which it is intelligently used and ones in which it isn't. Having a rendered dom with no content makes the user think, laggy site. Same if there's no async loading. Having a rendered dom with partial content (in particular the most important parts) will make the user happy and think, fast site – even when all the other widgets are still loading in background. The point is that as applications get larger, web developers should start making conscious decisions about load order of asynchronous scripts: load the stuff that is important to your users first. At the moment, too many large apps load everything simultaneously.

  2. Poelinca Dorin

    You forgot to mention why should one use async loading: The browser downloads the scripts WHILE it renders the dom, so eaven for heavy js apps this is actualy a speed bonus. Instead of waiting 15-20 ( or the "30' ) seconds BEFORE the page actualy starts rendering, "you can start to load" the scripts at the same time the dom is rendering, so the overall time from the page request till the user can actualy type is decresed .

    The problem you mentioned that the user gets "frustrated" before he can actualy start using the app ( seeing the dom allready loaded ) can be bypassed rather easy: breaking the code into smaller pieces of modules each with it's well defined functionality, browser caching, lazy loading … bla bla bla … combine that with AMD and the "dom loaded" event will fire much faster .

    I totaly disagree with you're statement, for smaller js apps you don't actualy need async loading becouse the user can't actualy feal any difference, while for large apps the user will allways be "happyer" if he actualy sees the dom rendered ( eaven tough he can't actualy interact with the app just yet ) or else waiting "30" seconds before he actualy sees anything he will blame the site for being slow !

    p.s. excuse my bad english


Leave a Reply

Your email address will not be published.