I benchmarked also, using a homebrew console.debug(new Date().getTime()), and consistently got about 90ms to load jQuery, plus another 100ms to load all the plugins and custom JS. That's a lot of time - in the sense of a browser based web app that is supposed to be highly reactive.
One alternate idea to frames is to load jQuery at the end of the page. That way, the user can see the entire page while jQ loads in the background, See http://developer.yahoo.com/performance/rules.html#js_bottom (thanks for the tip, Karl). On Nov 4, 5:11 pm, "Jeffrey Kretz" <[EMAIL PROTECTED]> wrote: > I just tried looking through the various parts of Firebug, and while it > profiles net traffic excellently, I don't see anyway to profile memory/CPU > time on the different elements. > > I did test a script which captures the date/time, then loads the jQuery > file, then captures the date/time again and calculates the millisecond > difference between them. > > You can see this (using uncompressed > jQuery):http://www.scorpiontechnology.com/Cobalt/speedtest.htm > > After clearing the cache and visiting the page (reflushing the cache each > time), I got these results: > > 1078ms > 1109ms > 1078ms > 1078ms > > Subsequence hits to the page (using the retry link) were: > > 16ms > 15ms > 0ms > 16ms > > I then made another page that uses the packed version of jQuery which has to > be eval'ed on load. > > http://www.scorpiontechnology.com/Cobalt/speedtest2.htm > > Initial load test: > > 641ms > 656ms > 656ms > 640ms > > Subsequent visits using the retry button (with cached files): > > 47ms > 32ms > 46ms > 47ms > > So there is definitely some overhead evaling the packed version of the > script, on the order of magnitude of about 0.03 seconds. > > Then, for poops and giggles, I tried the same thing with a minified gzip > jQuery: > > http://www.scorpiontechnology.com/Cobalt/speedtest3.htm > > Initial load test: > > 485ms > 468ms > 469ms > 562ms > > Subsequent cached loads were: > > 15ms > 16ms > 0ms > 16ms > > (identical to the initial uncompressed jQuery test). > > I'd be curious to see if others get similar results, but for now, I would > say that using the minified/gzipped solution will result in the least amount > of network overhead (duh) without the (albeit minor) performance hit of the > packed version. > > And on the original point about framesets, 0.016 seconds savings in time is > not worth the problems inherent in a frameset-based website IMHO. > > JK > > -----Original Message----- > From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On > > Behalf Of S. Robert James > Sent: Sunday, November 04, 2007 12:37 PM > To: jQuery (English) > Subject: [jQuery] Re: Drastically reducing jQuery load time > > On Nov 4, 3:04 pm, "Jeffrey Kretz" <[EMAIL PROTECTED]> wrote: > > I would need to see some actual stats as to the performance hit of the > > jQuery file loading itself into memory before I had this concern. > > Is there a good way to profile page load, and determine how much time > is spent parsing/executing jQuery, how much is spent on CSS, how much > is spent on screen paint, etc.? (This would have tremendous use > outside of this particular question...)
