For what I know, it depends on the script itself. And sometimes there’s no proof where it is better.
I’ve always gotten inconsistent results with loading it in the bottom of the body, and never found the performance gains touted, so I keep them in the head whenever possible.
Jeff,
I was referring specially to the JQ lib (or any other lib) as the other scripts may or may not be dependent on it.
Also it is good practice to to put scripts at the end of your document simply because by then your entire DOM has been built so it wont affect the loading of content or script execution. Depending on the script and how it is used it may help organization to have it within the HEAD.
If moving scripts to the bottom is causing anyone’s page to fail (or otherwise behave inconsistently), then that’s worth starting a thread about so the community can help discover the problem. Otherwise, having scripts at the bottom improves loading times both perceptively and objectively.
Here’s a concrete example:
Scripts loaded in the head: The page is blank for quite a while, then finally loads after about 7 - 7.5 seconds.
http://stevesouders.com/cuzillion/?c0=hc5hfff1_0_f&c1=hj1hfff2_2_f&c2=hj1hfff2_2_f&c3=bi3hfff1_0_f&c4=bf4hfff1_0_f&t=1343940321
Scripts loaded at bottom of the body: The page content (the image and the iframe) is displayed comparatively quickly, and the total load time is down to 6 - 6.5 seconds.
http://stevesouders.com/cuzillion/?c0=hc5hfff1_0_f&c1=bi3hfff1_0_f&c2=bf4hfff1_0_f&c3=bj1hfff2_2_f&c4=bj1hfff2_2_f&t=1343940419181
In these examples, the download times were designed to take a long time (e.g., 2 seconds) in order to highlight the difference. In a real world site, the difference might be just a few hundred milliseconds, depending on how much JavaScript you use, but it’s a benefit nonetheless.
It all depends though - having the scripts at the bottom can cause a flash of unscripted content, or users being able to interact with the page before the scripts have loaded. Could be undesirable in some circumstances - like I said in my post, it’s arguable - it would depend on the circumstances a lot.
Optimize the order of styles and scripts
Because JavaScript code can alter the content and layout of a web page, the browser delays rendering any content that follows a script tag until that script has been downloaded, parsed and executed. However, more importantly for round-trip times, many browsers block the downloading of resources referenced in the document after scripts until those scripts are downloaded and executed. On the other hand, if other files are already in the process of being downloaded when a JS file is referenced, the JS file is downloaded in parallel with them.
Therefore, since stylesheets should always be specified in the head of a document for better performance, it’s important, where possible, that any external JS files that must be included in the head (such as those that write to the document) follow the stylesheets, to prevent delays in download time.
Another, more subtle, issue is caused by the presence of an inline script following a stylesheet.
In this case, the reverse problem occurs: the first stylesheet actually blocks the inline script from being executed, which then in turn blocks other resources from being downloaded. Again, the solution is to move the inline scripts to follow all other resources, if possible.
Recommendations
Put external scripts after external stylesheets if possible.
Put inline scripts after other resources if possible.
A hands on solution is deferring.
[…] you should first identify all of the JavaScript functions that are not actually used by the document before the onload event.
Then, you insert a JavaScript event listener in the head of the containing document that forces the external file to be loaded after the onload event.
It’s safe to say that meta comes first, CSS comes second, content comes third, and everything not critical goes from the head to the bottom of the page.
Since this is the part you emphasized, I just want to make sure it’s understood that this doesn’t mean DOM manipulation. It means document.write, which is generally frowned upon and avoided anyway.
One problem with the Google’s approach of moving script at the bottom is visible in their Translate.
On slower connections, you’d have all the interface visible just not ready to action. The languages From and To lists won’t be available at first immediate clicks and the switch between Translation and Original views is also not immediately available, but the buttons are already visible and styled. You may waste some clicks before the javascript code is fully loaded and the user experience may suffer from this.
Very true. That’s the flash of unscripted content that Stormrider also mentioned. The usual fix for that is actually pretty simple. You can add a class to the <html> tag called “js-loading”, then in your CSS, you can do .js-loading .some-widget-that-depends-on-js { display: none }, or you can choose to display a spinner instead, and either of those are only necessary if your content is useless without JavaScript. Then the very last action taken by your JavaScript would be to remove the “js-loading” class, revealing your fully functioning JS widgets.
Be aware, however, that even if your scripts were all in the head, you could still get a flash of unscripted content, because we’re still forced to delay our script executions until the DOM ready event.
I’m not getting the flash, I’m just getting the delayed usability.
Either way, it’s a problem. But if Google, and Yahoo, and Bing, and Mozilla, and Microsoft (not Apple though, and not Opera!) chose this path, scripts at the bottom, there must be something to it.
As a side note, a spinner would give the wrong signal (meanwhile the impatient user wanders about the seriousness of the website: maybe something is not working, something is not right).
That’s actually what we mean. The term is a derivative of “flash of unstyled content,” which is the same kind of problem but manifests differently.
The DOM ready event would ordinarily occur before the page is rendered though
OK, now I feel FOUC-stupid…
The DOM ready event would occur before the onload event, but browsers render markup as it becomes available.
The demos I linked to earlier demonstrate this behavior.
The image and iframe are rendered even though the DOM ready event doesn’t fire until 6 seconds later.
… but we don’t know the exact moment when the DOM changes reflect in rendering… parsing starts immediately, rendering may come to a halt…
Of course. But if rendering halts, then the DOM ready event will also be delayed.
For example:
In the demo I linked to two posts up, click Edit, then drag one or both of the external scripts so that they are in between the image and the iframe, then click Create to run the page.
What happens is the image (but not the iframe) is rendered, then rendering halts while the scripts are being processed, and finally 6 seconds later, the iframe is rendered, followed shortly by the DOM ready event.
[ot][QUOTE=itmitică;5161695]“give a bitter reason/explanation” … Is it another test or should I take that personal? ;)[/QUOTE]
Ha ha, no, just another typo.
Yes, I’m thinking I should have said I’d give points for good answers and deduct points for bad ones. Think I’ll go that way. Feeling my way along here. 
[/ot]
Nice examples, and nice page, never heard of Cuzillion before this. Not sure how accurate it is, but a nice tool.
Off Topic:
I’m sorry to inform you but Pandora’s Box is open now: http://www.sitepoint.com/forums/showthread.php?870609-quot-Spot-the-Error-quot-Competition-2-Olympic-Edition&p=5161731&viewfull=1#post5161731
Wow, code Olympics huh… This seems to be fun but it will take time before I finished to spot those errors haha