JQuery document.ready() overhead

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").clic开发者_StackOverflow社区k(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.

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.

jQuery fails gracefully when a selector doesn't match so the only real performance hit you are getting is the fact that jQuery does a search for each selector. While this could be a potential bottleneck if you were trying to register a few thousand handlers, it's unlikely to be noticeable at 100.

Further more, if you are registering them to id (#) it doesn't even have to search the entire DOM, so the penalty is even more less noticeable.

jQuery docs on id search:

For id selectors, jQuery uses the JavaScript function document.getElementById(), which is extremely efficient.

My perspective from my research:

• Put all of your functions in a single file that gets loaded once with long expires headers.
• I recommend putting ALL js in one file (you can use if (location.pathname) to only run some on each page.
• Use comments and it will be maintainable
• If u really want some js per page.. still keep all the functions in 1 js file, but you can have different js to load each of the functions on the top of each page.... i guess

If you place your startup code for every single page, in a seperate external file, this would not be maintainable at all. Just stick with per page solution.

I would suggest you to stick with per page implementation because there is not point in having the code which is not going to do anything on the page but will consume the memory. You can even render $(document).ready(approPriatefunctionName); from server side per each page and make sure the required functions are defined in the js and they are loaded before you render this js script.

I think that you should store all of your functions in one large file. This is easier to maintain, and when minified it will load up quickly. Once this is stored in the user's cache then it does not reload each time.