I should add my platform: Firefox 2 Win XP Pentium Core Duo jQuery 1.2.1 minified cached
On Nov 4, 8:02 pm, "S. Robert James" <[EMAIL PROTECTED]> wrote: > 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, > Seehttp://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: [email protected] [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...)
