> and thus wait for 30/x HTTP roundtrips, where x is the number of allowed concurrent connections
Which is 1.
This is javascript here, not CSS or images. The default behaviour is to stop everything, download the script file (synchronously) then execute it (also synchronously) then resume. This means the default is to download then execute one JS file at a time (which is why you should always put your CSS files before your JS files).
Concurrent download (let alone out-of-order execution) have to be opted-in via specific attributes:
@async will queue script download (asynchronously) and execute it whenever it can once downloaded. Multiple @async scripts may be executed in any order, depending how fast they arrive and when the browser finally decides to exec them. It is supported in webkit-ish browsers, Firefox (>= 3.6) and MSIE >= 10
@defer will also queue script download but it guarantees the scripts will only be executed 1. between parsing and end DOMContentLoaded triggering, 2. in order. It is suported in webkit-ish browsers, Firefox (>= 3.5) and MSIE >= 10 (MSIE has had it since ~IE5, but as usual its behavior tends to be ill-defined and buggy)
(note: this is for <script src> tags in the downloaded source, not when they're dynamically inserted)
This isn't the case, I just verified it.
A test.html page with <script src="dummy32k-a.js"> and another for dummy32k-b.js show as downloading concurrently in chrome devtools network timeline.
It makes sense since the HTTP fetch order doesn't affect semantics as long as you obey the execution order from the page. Unless you're doing something very contrived, such as serving them as no-cache and generating different js dynamically from server side if a previous script has been requested...
Last I checked, browsers (chrome? firefox?) only allow 6 concurrent downloads from a web server. Do all resources load concurrently if you have seven large javascripts in a page?
Which is 1.
This is javascript here, not CSS or images. The default behaviour is to stop everything, download the script file (synchronously) then execute it (also synchronously) then resume. This means the default is to download then execute one JS file at a time (which is why you should always put your CSS files before your JS files).
Concurrent download (let alone out-of-order execution) have to be opted-in via specific attributes:
@async will queue script download (asynchronously) and execute it whenever it can once downloaded. Multiple @async scripts may be executed in any order, depending how fast they arrive and when the browser finally decides to exec them. It is supported in webkit-ish browsers, Firefox (>= 3.6) and MSIE >= 10
@defer will also queue script download but it guarantees the scripts will only be executed 1. between parsing and end DOMContentLoaded triggering, 2. in order. It is suported in webkit-ish browsers, Firefox (>= 3.5) and MSIE >= 10 (MSIE has had it since ~IE5, but as usual its behavior tends to be ill-defined and buggy)
(note: this is for <script src> tags in the downloaded source, not when they're dynamically inserted)