Improving Javascript Load Times - Concatenation vs Many + Cache

Question

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.

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).

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.

The system I currently have is something like this

• All javascript files are compressed and loaded at the bottom of the page
• All javascript files have far future cache expiration dates, so will remain (for most users) in the cache for a long time
• Pages only load the javascript files that they require, rather than loading one monolithic file, most of which will not be required

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).

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.

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).

I'm also looking at using LabJS to allow for parallel loading of the JS when it's not cached.

Specific questions

• 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?
• Are there any other reasons to prefer one over the other?
• Does similar thinking apply to CSS? (I'm currently using a much more monolithic approach to CSS)

Answer 1

I would definitely go with the non-monolithic approach. Not only in your case, but in general gives you more flexibility when you need something changed or re-configured.

If you make a change to one of these files then you will have to merge-compress and deliver. If you are doing this in an automated way then you are OK.

As far as the browser question "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", i think that there is an HTTP request made but the with response "NOT MODIFIED". To be sure you should check all the Requests made to the Web Server (using one of the tools available). After the response is given then the browser uses the unmodified resource - the js file or image or other.

Good luck with your B2B.

Answer 2

Did you try Google Closure? From what I've read about it it seems quite promissing.

• http://code.google.com/closure/

• http://googlecode.blogspot.com/2009/11/introducing-closure-tools.html - blog post

• http://axod.blogspot.com/2010/01/google-closure-compiler-advanced-mode.html - performance of GC

• http://www.sitepoint.com/blogs/2009/11/12/google-closure-how-not-to-write-javascript/ - a few tips for javascript

Answer 3

Generally it's better to have fewer, larger requests than to have many small requests, since the browser will only do two (?) requests in parallel to a particular domain.

So whilst you say that most users are repeat visitors, when the cache expires there will be many round-trips for the many files, rather than one for a monolithic file.

If you take this to an extreme and have potentially thousands of files with individual functions in them, it would become obvious that this would lead to a huge number of requests when the cache expires.

Another reason to have a monolithic file is for when various parts of the site have different chunks of javascript associated with them, as you again get this in the cache when you hit the first page, saving later requests and round-trips.

If you're worried about the initial hit loading a "large" javascript file you can try loading it asynchronously, using the method described here : http://www.webmaster-source.com/2010/06/07/loading-javascript-asynchronously/

Whichever way you go in the end, remember that since you're setting a far-future modified date, you'll need to change the name of the javascript (and CSS) files when changes are made in them, otherwise clients won't pick up the changes until their cache expires anyway.

PS : Profile it on the different browsers with the differing methods and write it up, as it will prove useful to those who are also stuck on slow JS engines like IE6 :)

Answer 4

Even though you are dealing with repeat-visitors, there are many reasons why their cache may have been cleared, including privacy and performance tools that delete temporary cache files to "speed up your computer".

Merging and mini-fying your script doesn't have to be an onerous process. I write my JavaScript in separate files, nicely spaced out to be readable to me so it is easier to maintain. However, I serve it via a script page that combines all of the scripts into a single script and mini-fies it all - so one script gets sent to the browser with all my scripts in. This is the best of both worlds as I work on a collection of JavaScript files that are all readable, and the visitor gets one compressed JavaScript file, which is the recommendation for reducing the HTTP requests (and therefore the queue time).

Answer 5

I've used the following for both CSS and Javascript -- most of my pages in Google Speed report being 94-96/100 and they load very fast (always within a second, even if there are 100kb's of Javascript).

1. I have a PHP function to call files -- this is a class and stores all the unique files that are asked for. My call looks something like:

javascript( 'jquery', 'jquery.ui', 'home-page' );

2. I spit out a url-encoded version of these strings combined together to call a dynamic PHP page:

<script type="text/javascript" src="/js/?files=eNptkFsSgjAMRffCP4zlTVmDi4iQkVwibbEUHzju3UYEHMffc5r05gJnEX8IvisHnnHPQN9cMHZeKThzJOVeex7R3AmEDhQLCEZBLHLMLVhgpaXUikRMXCJbhdTjgNcG59UJyWSVPSh_0lqSSp0KN6XNEZSYwAqt_KoBY-lRRvNblBZrYeHQYdAOpHPS-VeoTpteVFwnNGSLX6ss3uwe1fi-mopg8aqt7P0LzIWwz-T_UCycC2sQavrp-QIsrnKh"></script>

3. That dynamic PHP page takes decodes the string and creates an array of the files that will needed to be called. A cache_file path is created:

$compressed_js_file_path = $_SERVER['DOCUMENT_ROOT'] . '/cache/js/' . md5( implode( '|', $js_files ) ) . '.js';

4. It checks to see if that file path already exists in the cache, if so, it just reads the file:

if( file_exists( $compressed_js_file_path ) ) {
    echo file_get_contents( $compressed_js_file_path );
} else {

5. If it doesn't exist, it compresses all the javascript into one "monolith" file, but realize it has ONLY the necessary javascript for that page, not for the entire site.

if( $fh = @fopen( $compressed_js_file_path, 'w' ) ) {
    fwrite( $fh, $js );
    fclose( $fh );
}

// Echo the compressed Javascript
echo $js;

I've given you excerpts of the code. The program you use to compress javascript is completely up to you. I use this with both CSS and Javascript so that all those file requires 1 HTTP request, ever, the result is cached on the server (simply delete that file if you change something), and it has only the necessary Javascript & CSS for that page.

Answer 6

I really think you need to do some measurement to figure out if one solution is better than the other. You can use JavaScript and log data to get a clear idea of what your users are seeing.

First, analyze your logs to see if your cache rate is really as good as you would expect for your userbase. For example, if each html page includes jquery.js, look over the logs for a day--how many requests were there for html pages? How many for jquery.js? If the cache rate is good, you should see far fewer requests for jquery.js than for html pages. You probably want to do this for a day right after an update, and also a day a few weeks after an update, to see how that affects the cache rate.

Next, add some simple measurements to your page in JavaScript. You said the script tags are at the bottom, so I assume it looks something like this?

<html>
<!-- all your HTML content... -->
<script src="jquery.js"></script>
<script src="jquery-ui.js"></script>
<script src="mycode.js"></script>

In that case, you time how long it takes to load the JS, and ping the server like this:

<html>
<!-- all your HTML content... -->

<script>var startTime = new Date().getTime();</script>

<script src="jquery.js"></script>
<script src="jquery-ui.js"></script>
<script src="mycode.js"></script>

<script>
var endTime = new Date().getTime();
var totalTime = endTime - startTime; // In milliseconds
new Image().src = "/time_tracker?script_load=" + totalTime;
</script>

Then you can look through the logs for /time_tracker (or whatever you want to call it) and see how long it's taking people to load the scripts.

If your cache rate isn't good, and/or you're dissatisfied with how long it takes to load the scripts, then try moving all the scripts to a concatenated/minified file on one of your pages, and measure how long that takes to load in the same way. If the results look promising, do the rest of the site.

Answer 7

I would say that the most important thing to focus on is the perception of speed.

First thing to take into consideration, there is no win-win formula out there but a threshold where a javascript file grows into such a size that it could (and should) be split.

GWT uses this and they call it DFN (Dead-for-now) code. There isn't much magic here. You just have to manually define when you'll need a need a new piece of code and, should the user need it, just call that file.

How, when, where will you need it?
Benchmark. Chrome has a great benchmarking tool. Use it extensivelly. See if having just a small javascript file will greatly improve the loading of that particular page. If it does by all means do start DFN'ing your code.

Apart from that it's all about the perception.

Dont let the content jump!
If your page has images set up their width's and heights up front. As the page will load with the elements positioned right where their are supposed to be, there will be no content fitting and adjusting the users perception of speed will increase.

Defer javascript!
All major libraries can wait for page load before executing javascript. Use it. jQuery's goes like this $(document).ready(function(){ ... }. It doesn't wait for parsing the code but makes the parsed code fire exactly when it should. After page load, before image load.

Important things to take into consideration:

1. Make sure js files are cached by the client (all the other stand short compared to this one).
2. Compile your code with Closure Compiler
3. Deflate your code, its faster than Gziping it (on both ends)

Apache example of caching

// Set up caching on media files for 1 month
<FilesMatch "\.(gif|jpg|jpeg|png|swf|js|css)$">
    ExpiresDefault A2629744
    Header append Cache-Control "public, proxy-revalidate"
    Header append Vary "Accept-Encoding: *"
</FilesMatch>

Apache example of deflating

// compresses all files for faster transfer
LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/html text/plain text/xml font/opentype font/truetype font/woff
<FilesMatch "\.(js|css|html|htm|php|xml)$">
   SetOutputFilter DEFLATE
</FilesMatch>

And last, and probably least, serve your Javascript from a cookie-less domain.

And to keep your question in focus, remember that when you have DFN code you'll have several smaller javascript files that, precisely for being split, wont have the level of compression Closure can give you with a single one. The sum of the parts isn't equal to the whole in this scenario.

Hope it helps!