views:

175

answers:

4

I have several javascript files that during run-time get combined and minified. This is for an enterprise application with 10+ developers. There are document.ready functions all over the place causing 5+ second javascript load. I'd like more help in figuring out where the bottlenecks are by slowly removing pieces of functionality.

E.g.

file1.js

$(document).ready(function() {
  // 100s of lines of code
});

file2.js

// 100s of lines...
$(document).ready(function() {

  // 100s of lines of code

});
// 100s of lines...

I'd like to include some kind of metrics so I can slowly comment different functions and see what is actually making a difference. Essentially I need a way to monitor the overall time it takes for document.ready to run.

I'm thinking maybe I can use jQuery to accomplish this. Maybe change all the $(document).ready's in my project to use the jquery wrapper and then put a timer around that. Alternatively I could run a function as the very first script (before the combined/minfied file is included) to start a timer. I'm just not sure when that timer could stop and display. Any ideas?

Edit: I know firebug can achieve this but I'm working on a huge enterprise application and firebug is unfortunately not an option for me at this time. I'm really hoping just to attach a number to the HTML. E.g.:

document.ready time: 653ms

+1  A: 

I think the first thing you should do is fire up Firebug or Safari profiler and see what's actually taking all the time.

After this, using Page-Speed and YSlow can help you find more about the load speed bottlenecks.

Just having more than one listener on document.ready should not really slow things down - it's lilkely either the code that runs on those listeners, or the amount of code you are loading.

Jani Hartikainen
Firebugs Profile feature is definitely the right tool for this problem. +1
MitMaro
I'd love to use firebug but unfortunately this is an enterprise app designed solely for IE6. For some reason the javascript doesn't work when I try to run it in firefox and I don't have the time to figure that one out yet.I guess I could try firebug lite for IE but I was hoping to just get an overall number I could stick at the top of the page so other developers on my team could use it as well
macca1
Unless you're using ActiveX, it should be relatively simple to fix it to work for other browsers. It would make your job much easier, and if your boss doesn't like the idea, tell him in the future IE6-only apps may not function - Would your employer want to have wasted their money that much? ;)
Jani Hartikainen
A: 

Thanks to blesh, this is the solution I was looking for:

edit the production jQuery-1.3.2 and surround the jQuery.ready() call with this:

var startTime = new Date(); 
jQuery.ready(); 
var endTime = new Date(); 
var difference = endTime - startTime; 
alert("document.ready time: " + difference + " milliseconds");

The jQuery.ready() is line 3066 for IE.

And of course the alert can be replaced with something that outputs right to the screen, depending on your layout.

Thanks blesh!

macca1
I'm not sure what this buys him, other than a time spanning the entire ready() execution. Besides, wouldn't it be easier just to go into jQuery.ready() in the jquery unminified file and put the speed check around that?Maybe it would be better to locate some suspect code and time those regions?
blesh
A: 

It's not the number of $(document).ready(fn) calls that is getting you... if you take a look at the inner workings of jQuery, it's not doing anything fancy. It's simply putting all of the functions you pass in into an array and then executing each one when jQuery.ready() is called once the DOM is loaded.

If I were you, I'd take a look at a few things:

  1. How big is your html output? Are there tons of nested elements? That could slow the DOM loading.
  2. Are you doing a lot of ajax calls at the outset of your page load that you have to wait for before your scripts can complete?
  3. Are you using really inefficient selectors with jQuery? there are quite a few posts about that around here.

Hopefully that helps.

blesh
Thanks for the suggestions. You are right -- I am looking at everything you mentioned and more. The purpose of the question was though to install metrics so that when I do look at the things you outlined, I can see what improvements are actually making a difference. Your solution above is what I was looking for though.
macca1
A: 

If you're stuck on IE6, dynaTrace Ajax could be worth looking in to. It should allow to inspect and profile the scripts in ways similar to what you do in Firebug's profiler. This would save you the code changes...

Unfortunately I have no personal experience with it (yet), but others have (see the testimonials for links. Sorry, but I don't have enough rep. to post the links here).

Samuel Sjöberg