The JavaScript placement debate

A few years ago, Yahoo released a free benchmarking tool for web pages. Aka Yslow. This tool is measuring what and when loads, during a pageview. It then gives a report about what is slowing down your page and then makes some recommendations on how you can improve the performance of your site.

One of these recommendations is that you should load your JavaScript in the bottom of the page, right before the closing </body> tag. The Yahoo people even went so far as to call this a “best practice”. Ever since, there is an ongoing debate among developers about the right place to load JavaScript files. Most people are indeed consider placing JavaScript in the bottom of the page a best practice. Is it so ?

When you put your JavaScript at the top of the page, the browser will start loading your JS files before the markup, images and text. And since browsers load JavaScript synchronously, nothing else will load while the JavaScript is loading. So there will be a timeframe of a few seconds where the user will see a blank page, while the JavaScript is loading.

On the other hand, if you place your JavaScript at the bottom of the page, the user will see the page loading first, and after that the JavaScript will load in the background. So if for example your CSS & HTML takes 5 seconds to load, and your JavaScript takes another 5 seconds, putting our JavaScript on the top of the page will give the user a “perceived” loading time of 10 seconds, and putting it on the bottom will give a “perceived” loading time of 5 seconds.

I’m using the word perceived, because in both cases the page will be completely loaded in the same amount of time. In whatever order you place your assets, they still take the same time to load. All we can achieve by placing JavaScript at the bottom is how fast the user thinks the page has loaded. But still it sounds amazing, right ? By putting JavaScript at the bottom of the page, our pages will appear to be loading twice as fast.

The perception of “the web”

Well this used to be the big picture in the past. Back then, when the web was something very different from what it is today. Overgeneralizing, for the sake of simplicity, this is how the web was perceived by almost everyone (including web professionals) until recently.

Since then much have changed. First and most important, we don’t talk about “web pages” these days. We now talk about “web apps”, “software in the cloud” and “software as a service”. The web used to be more like digital paper. A way to let people know about your company, a platform for your blogging, at best a place to read your email remotely. But now in 2013 the web is quickly replacing the remnants of desktop software and is battling toe to toe with Java and Objective-C, for domination on mobile devices.

All these concepts were a utopia, no more than five years ago. But today the content is no longer the king. The web is now a democracy. People don’t come to us for content anymore, they create it themselves. Our role as web developers is to empower them, by giving them the tools and functionality to create and interact with their content.

Forget about supporting IE6 and browsers without JavaScript. This is just a 5% of people who fear change, like some people never bothered to buy a computer at all. In a world where we are competing with native mobile developers over performance and features, we can’t afford to think of the web as anything other than pure software. In a way, functionality is the new content and JavaScript is the new king.

JavaScript placement in web applications

Back to our topic. Let’s get back to our example, where we load our JavaScript at the bottom of the page. The user is left for a few seconds with a perfectly looking HTML template where nothing is functional. If the users tries to perform an action and finds out that it’s not working, he will perceive our application as “broken”. What’s even worse, is that we have no way of letting the user know when the app will be fully functional.

On the contrary if we place our JavaScript on top, the user will get a blank page for a few seconds, but once the markup is loaded, everything will be fully functional from the first second. Therefore by purposefully giving the user a blank page, we are giving him information that the app is still loading. The user knows that the app will be functional when he sees boxes and buttons.

The user may think that our app is slow, or that his connection is having hick-ups or even that his device is slow. Not only we don’t take the full blame for the slow loading of our app, but we eliminate the possibility of the user interacting with a broken version of our application.

A few seconds to load the app is one of the most common things in digital devices in general. People wait for computers to boot up, for youtube videos to load, for Microsoft Word to open, for almost everything. Nobody will go crazy for a couple more seconds of waiting. But there is nothing worse than a user tapping a button which does not work. This is a breach of trust from the user end. If the app didn’t function correctly now, will it lose my data tomorrow ? Should I pick another app instead ?

Even the slow loading experience can be eased, using a simple loader like Gmail did.

Summarising, it really depends on what you’re making. If you’re still stuck in the “content” world then it’s maybe best to place your JavaScript at the bottom of the page. But if you are making web software you’re much better, placing JavaScript at the top, because functionality is the new king.