Combining and minifying javascript

Recently I started using Minify to combine and compress javascript files.
I installed this in the directory “min” and can now call for example


That will combine functions.js and menu.js, minify it, and send it to the client gzipped.

All very nice, but my question is this:

Suppose I have a rather simple website with a home page, a FAQ and a contact form. On all these pages I want to load the functions.js and menu.js files, but on the FAQ page I also want to load a faq.js, and on the contact page I want to load a contact.js

Then, on the home I would request


On the FAQ page:


And finally on the contact page


To me it seems this is not very efficient in terms of caching since the client has to cache all three responses seperately and is not able to re-use functions.js and/or menu.js over the different pages.

Would it still make sense to do it this way, or should I just load all the javascript files I might ever need and then create an body onload event to initialise the scripts (since it doesn’t make sense to let the code in faq.js run on the contact page for example) ?
The drawback of this is of course that more javascript has to be downloaded, but has the big advantage that only has to be downloaded once, and can be loaded from the browser’s cache on each subsequent request.

How do other people do this?

Seeing as you’ll need to use only some of the scripts on some pages, and other scripts on other pages, it may be best to split them up and serve them individually.

It’s going to be a compromise, how ever you decide to do it. One big JS file only requires one HTTP request, which is obviously better than four separate requests. But then, the fact that it’s being cached becomes somewhat redundant, because, as you mentioned, users will have to download a new combination on other pages.

If you separate the files you also have the benefit of being able to make a change to one of them without requiring users to re-download a massive combined JS file – all they need to re-download is the single file that you changed.

FWIW, you shouldn’t be the “onload” event to kickstart your scripts. Check out various libraries’ implementations of the DOM-ready event. Ideally, you could do without that and place your initialisation code at the bottom of the document, just above </body>

I’m using jQuery and was actually thinking of putting

$(document).ready( function() { initFAQ(); } );

just above the </body> for the FAQ page, and initContact(); for the contact page, etc. Is that what you mean?

BTW, you make a good point that users need to download the complete js pack when I change one of the files. On the other hand, I rarely change javascript files once a site goes live, so I’m not that concerned about that.
I think the upside of being able to cache the file, and thus be able to load subsequent page visits faster and also reducing overall bandwith is more important to me than the visitors having to download the new js pack when I change a script.

This kinda stuff really depends on the situation. If combining it all into 1 file doesn’t result in some overly enormous beast, I’d lean towards doing that. Too many http requests can be a real killer on older browsers, and high latency networks.

But on some sites, especially if it’s very javascript heavy with many pages each with differing functionality, it gets hard to combine. Depends how much you wanna optimize too. If the javascript is very specific to the page, and not enormous, I personally think putting the javascript right into the document can be a real win. You can still externally link to a library or whatever common scripts you have.

That sounds like a good plan, I think I’ll go for this approach. :slight_smile:


Placing scripts within the document itself is only reasonable if it’s less than about 500 bytes – any more than that and it’s worth having it cached.

Read this: