JavaScript resources are never downloaded in parallel. They are downloaded sequentially because they are interpreted while they download, and (existing) browsers always run JavaScript in a single thread.
This will have very little effect on caching. You will still need to configure your web server for optimal caching, by setting the Cache-control and Expires headers, for example.
Even so, this still has two main benefits: The JavaScript is minified, which will reduce the amount of raw data sent to remote users. Plus, by concatenating all the files together, you avoid the need for multiple separate HTTP requests.
I had previously been told that a JavaScript download basically halts the entire processing of the remainder of the page -- including any downloads that might occur there (CSS, images, and more JS) -- because the browser can't start parsing the rest of the page until it has interpreted the JavaScript. That's why it's best to move your JavaScript down to the bottom of the page.
Is this just the way older browsers used to behave? Are there still any restrictions like this that I should be aware of?
My rule of thumb with javascript is to put everything that is critical to page functionality right at the top and everything else as far to the bottom as I can (just before </body>), that way all your buttons/sliders and other active components will work as soon as the page is rendered and any other javascript will never hurt performance.
It seems that concatenating scripts could hurt performance in browsers that can do parallel script downloading, since it can no longer take advantage of the parallelism.
Comments
JavaScript resources are never downloaded in parallel. They are downloaded sequentially because they are interpreted while they download, and (existing) browsers always run JavaScript in a single thread.
This will have very little effect on caching. You will still need to configure your web server for optimal caching, by setting the Cache-control and Expires headers, for example.
Even so, this still has two main benefits: The JavaScript is minified, which will reduce the amount of raw data sent to remote users. Plus, by concatenating all the files together, you avoid the need for multiple separate HTTP requests.
Incorrect. In the latest browsers, js can be downloaded in parallel, but executed in the correct order - sequentially.
AFAIK, that includes the latest safari, firefox, and IE8.
However, it's still obviously a good idea to concat and minify all your scripts.
Cool, thanks for the tidbit.
I had previously been told that a JavaScript download basically halts the entire processing of the remainder of the page -- including any downloads that might occur there (CSS, images, and more JS) -- because the browser can't start parsing the rest of the page until it has interpreted the JavaScript. That's why it's best to move your JavaScript down to the bottom of the page.
Is this just the way older browsers used to behave? Are there still any restrictions like this that I should be aware of?
My rule of thumb with javascript is to put everything that is critical to page functionality right at the top and everything else as far to the bottom as I can (just before </body>), that way all your buttons/sliders and other active components will work as soon as the page is rendered and any other javascript will never hurt performance.
There is a page describing which browesrs support which parallel download types at http://stevesouders.com/ua/report.php
It seems that concatenating scripts could hurt performance in browsers that can do parallel script downloading, since it can no longer take advantage of the parallelism.
It's be an interesting one to test, although I'd expect the gain in compression is worth it.
eg gzip(concat(A, B)) compresses to a smaller file than gzip(A) + gzip(B)
For example, if I take 20 js files from Mibbit and gzip them individually, total size is 47,890 If I concat then gzip, it's 42,681