title: Improving Javascript Load Times - Concatenation vs Many + Cache
body: <p>I'm wondering which of the following is going to result in better performance for a page which loads a large amount of javascript (jQuery + jQuery UI + various other javascript files).  I have gone through most of the YSlow and Google Page Speed stuff, but am left wondering about a particular detail.</p>
  
  <p>A key thing for me here is that the site I'm working on is not on the public net; it's a business to business platform where almost all users are repeat visitors (and therefore with caches of the data, which is something that YSlow assumes will not be the case for a large number of visitors).</p>
  
  <p>First up, the standard approach recommended by tools such as YSlow is to concatenate it, compress it, and serve it up in a single file loaded at the end of your page.  This approach sounds reasonably effective, but I think that a key part of the reasoning here is to improve performance for users without cached data.</p>
  
  <p>The system I currently have is something like this</p>
  
  <ul>
  <li>All javascript files are compressed and loaded at the bottom of the page</li>
  <li>All javascript files have far future cache expiration dates, so will remain (for most users) in the cache for a long time</li>
  <li>Pages only load the javascript files that they require, rather than loading one monolithic file, most of which will not be required</li>
  </ul>
  
  <p>Now, my understanding is that, if the cache expiration date for a javascript file has not been reached, then the cached version is used immediately; there is no HTTP request sent at to the server at all.  If this is correct, I would assume that having multiple  tags is not causing any performance penalty, as I'm still not having any additional requests on most pages (recalling from above that almost all users have populated caches).</p>
  
  <p>In addition to this, not loading the JS means that the browser doesn't have to interpret or execute all this additional code which it isn't going to need; as a B2B application, most of our users are unfortunately stuck with IE6 and its painfully slow JS engine.</p>
  
  <p>Another benefit is that, when code changes, only the affected files need to be fetched again, rather than the whole set (granted, it would only need to be fetched once, so this is not so much of a benefit).</p>
  
  <p>I'm also looking at using <a href="http://www.labjs.com/" rel="noreferrer">LabJS</a> to allow for parallel loading of the JS when it's not cached.</p>
  
  <p>Specific questions</p>
  
  <ul>
  <li>If there are many  tags, but all files are being loaded from the local cache, and less javascript is being loaded overall, is this going to be faster than one  tag which is also being loaded from the cache, but contains all the javascript needed anywhere on the site, rather than an appropriate subset?</li>
  <li>Are there any other reasons to prefer one over the other?</li>
  <li>Does similar thinking apply to CSS? (I'm currently using a much more monolithic approach to CSS)</li>
  </ul>