JQuery document.ready() overhead

Question

I'm working with an application that uses way more JQuery that I've dealt with before and I'm trying to understand what JQuery document.ready() does to a web application a little better. I'm hoping that someone more experienced in JS/JQuery could help me out.

Let's assume I have an separate .js file with 100 JQuery functions inside a document.ready():

$(document).ready(function() {
  $("#something1").click(function() { ... });
  $("#something2").click(function() { ... });
  $("#something3").click(function() { ... });
  etc...
});

I understand that these would now be loaded and ready for every page of the website (through the inclusion of the .js file). However, I could also stick these inside separate document.ready() functions on every individual page of the website, where each page would only get what it actually uses. Or I could craft something even more sophisticated by selectively calling functions that group event handlers inside the document.ready();

Given that the entire .js file is in any case read by the browser, I would like to know what kind of effect there might be between these approaches on performance. It seems counter-intuitive to load all the event handlers for every page but at the same time this has me wondering whether I'm creating a problem out of something that actually isn't.

A little outside perspective would be useful. Thanks.

Answer 1

The best overall result is often achieved by creating a library of code that can be made available to all your pages in one minified external JS file. Then, put page-specific initialize code either inline with the page or in an external JS file specifically for that page.

This has the following advantages:

1. You only have one copy of all your functions so it's easier to maintain.
2. The one minified external JS file can be very effectively cached by the browser. It will load with the first page that the viewer hits and from then on be served from the browser cache.
3. You are only running initialization code that is appropriate for the particular page being displayed. If you mix all your initialization code together and just let a lot of it silently fail because it's actually for other pages, you can quickly create quick a big mess and in a large site, you could have quite a performance hit running all those initialization functions and looking for DOM objects that aren't there.
4. It's much easier to debug if the only initialization functions that are running are the ones that are supposed to work.
5. With the external JS in the one cacheable external file, you can minimize the number of external files that need to be loaded if the initialization code for a particular page is included inline in the actual web page rather than in it's own external JS file. For fastest perceived page display performance, it should be after all the HTML of the page.

For further optimizations in a large project, if the external JS file is very large and you have a large classification of functions that are only needed in one part of the site, then you could break those into another external JS file that is only included in that part of the site. Because these files are cached effectively by the browser, the main savings is in interpreter parsing time and memory footprint which may or may not be significant (it depends on how large the project is). There is usually a practical limit to these optimizations because loading several external JS files usually takes more time than loading one larger one.

Be sure to appropriately version number your external JS files, so when you revise them the filename changes so that browsers are forced to fetch the new version and don't get stuck on the old version from cache.