Loading Javascript files in parallel

You’ve got your website all set up but are experiencing slow load times for some customers, especially on slower connections. One possible cause is inefficient network usage because of serialized loading of external Javascript files.

Static links in <head>

If you include script files in the HEAD element both IE and Firefox will download the scripts serially, waiting for each one to finish downloading before proceeding with the next one. Take the following HTML snippet that loads two external javascripts:



    <script type=”text/javascript” src=”Script1.js”></script>

    <script type=”text/javascript” src=”Script2.js”></script>


Network traffic for loading scripts in <head> tag

In this common scenario a large amount of network bandwidth can potentially go unused.

Loading the scripts in parallel

You have two options for loading scripts in parallel:

  • Attach them as elements dynamically
  • Use document.write to attach them

Both of these options will produce the same network traffic with the difference being in how the scripts are executed on the client. By loading the scripts in parallel we can cut down initial page load time drastically. The time for Script1.js to finish downloading will probably go up slightly over serial loading (since more of the connection is used) but the overall download time should decrease.

Network traffic for loading scripts in parallel 

Attaching scripts as elements dynamically


    <script type=”text/javascript”>

        function AttachScript(src)


            var script = document.createElement(“SCRIPT”);

            script.type = “text/javascript”;


            script.src = src;





  <script type=”text/javascript”>





In this scenario IE and Firefox will download both scripts but Internet Explorer will also execute them in the order they finish downloading in whereas Firefox downloads them asynchronously but still executes them in the order they are attached in the DOM.

In Internet Explorer this means your scripts cannot have dependancies on one another as the execution order will vary depending on network traffic, caches, etc.

In Firefox you can mostly get away with keeping dependancies on Script1 from Script2 with the caveat that if the user presses stop after Script2 has finished downloading but Script1 has not, Firefox will execute Script2 and abort downloading Script1. Ensure that Script2 can properly handle Script1 failing to load.

Attaching scripts via document.write

<script type=”text/javascript”>

  document.writeln(“<script type=’text/javascript’ src=’Script1.js’><“ + “/script>”);

  document.writeln(“<script type=’text/javascript’ src=’Script2.js’><“ + “/script>”);


Using document.write produces the same effect in both Internet Explorer and Firefox: the scripts are downloaded in parallel but executed in the order they’re written to the page. The same caveat above about the user stopping the page after Script2 has finished downloading before Script1 has applies.


This technique can be used to download more than two files at the same time as long as more than 1 hostname is used. IE will only open 2 HTTP connections to a named server in order to be a good client (Firefox will open 4) but you can easily work around this by creating additional domain names like scripts1.example.com, scripts2.example.com etc that point to the same host. At some point you will see diminishing returns and possibly even slowdowns from trying to download too many files at once so don’t go too crazy with parallelizing.

Edit: Noted that Firefox will open 4 connections per named host by default.

Comments (8)

  1. Gopinath says:

    Beauty Kris, can u explain abt  ‘creating additional domain names ‘  where to create or small example..



  2. Kristoffer says:

    Say you have 4 Javascript files to load and your domain is http://www.example.com. Instead of loading them all from http://www.example.com create another subdomain like scripts1 and scripts2.example.com. These can be just aliases for http://www.example.com and point to the exact same machine but browsers will see them as separate domains and issue up to 2 simultaneous requests per domain.

  3. Gopinath says:

    Cool Thx, I wll try it out..


  4. aric caley says:

    I had no idea javascripts loaded sequentialy until I started using the firebug firefox extension.  Using your little bit of magic I shaved several seconds off my page loads…

  5. rbirkby says:

    Actually, Firefox by default opens 4 connections to the same server. You can see this in about:config (network.http.pipelining.maxrequests). IE only opens 2 (in accordance with the HTTP spec)

  6. Fiann O'Hagan says:

    Thanks for the excellent survey. There’s one interesting case missing, which took us by surprise.

    If you use document.write() to create a new script on the page, but you include the body of the script in the write, rather than referencing an external file, it doesn’t behave the same way.

    It actually behaves in the way you have explained for attaching files dynamically through the DOM. In this case, since the code for the script is available immediately, it seems to be executed straight away.

    This caught us out because it broke our expectations of how the page code would be executed. It’s a very common pattern to load an external library, and then to have inline <script> blocks within the page HTML that call functions defined in the library. That works because the inline scripts are not executed until the library file has loaded and executed, so the functions are already defined.

    However you cannot write that script into the page, using something like this:

    document.writeln("<script type=’text/javascript’>callLibraryFunction();<" + "/script>");

    It will fail as the function is not defined when the script executes.

  7. Bisher war ich immer der Meinung, dass JavaScripts nicht von parallel Downloading profitieren können.Dies ist darin begründet, dass bei der Ausführung der Scripts die Seite manipuliert werden kann und somit sämtliche Browser alle JavaScripts schön sequ

  8. Jeff Griffith says:

    There is a very serious problem to watch out for here. The JavaScript interpreter and the HTML editor run in parallel and the HTML editor may not be able to force the JavaScript editor to abort. If an HTML event occurs that sets "document.location.href", the HTML editor will reload, but the JavaScript interpreter will continue loading the old scripts. Unfortunately, when the JavaScript interpreter tries to reference HTML objects, it will throw an exception because the HTML objects it is trying to reference no longer exist. While the window of opportunity is quite small, I have had users hit it. In my case, clicking on a checkbox caused the page to reload, whose HTML caused a second reload, which caused the JavaScript to fail, which aborted the reload and all users saw was a blank page (because error notifications were turned off).