[jQuery] Re: JQuery Size YUI Compressor mod_deflate/GZIP
Joel, Wow, I had no idea that packed JavaScript had to be unpacked on each page load! Ouch! So if I'm reading the data right on the JavaScript Library Performance Test Roundup it seems as though the way to go is defiantly the Yahoo minified script with GZIP at 131ms cached (731ms uncached). (Note to self: trust the Jquery folks because the Jquery homepage says to use the minified script if you have GZIP. Stop double testing everything and just do what *they* say.) Our site has only 250K visitors a month but 7.5 million hits. It's like 20 hits per page. I've got to start using CSS sprites. Ar.
[jQuery] Re: JQuery Size YUI Compressor mod_deflate/GZIP
Haha, you cracked me up :) I'm not sure of the figures for processing the packed version, however this would need to be done for every page of your site that the user visits because the JS is cached in packed form. This means that whatever the overhead is for unpacking the packed version, the delay is applied to every page of your site. For this reason, even if the regular minified (non-packed) version was even a bit larger than it is, I'd definitely lean towards using it as this can be cached once and used without delay on all subsequent pages. Yahoo released a paper about the time they release YSlow--which indicated that, much to everyone's surprise, browsers are not caching content as much as we might think they are. http://yuiblog.com/blog/2007/01/04/performance-research-part-2/ 40-60% of Yahoo!'s users have an empty cache experience and ~20% of all page views are done with an empty cache. To my knowledge, there's no other research that shows this kind of information. And I don't know about you, but these results came to us as a big surprise. It says that even if your assets are optimized for maximum caching, there are a significant number of users that will always have an empty cache. This goes back to the earlier point that reducing the number of HTTP requests has the biggest impact on reducing response time. The percentage of users with an empty cache for different web pages may vary, especially for pages with a high number of active (daily) users. However, we found in our study that regardless of usage patterns, the percentage of page views with an empty cache is always ~20%. I found this really informative and a little surprising (especially since I think most people who use Yahoo use it on a fairly frequent basis.) -Dan
[jQuery] Re: JQuery Size YUI Compressor mod_deflate/GZIP
40-60% of Yahoo!'s users have an empty cache experience and ~20% of all page views are done with an empty cache. To my knowledge, there's no other research that shows this kind of information. And I don't know about you, but these results came to us as a big surprise. It says that even if your assets are optimized for maximum caching, there are a significant number of users that will always have an empty cache. This goes back to the earlier point that reducing the number of HTTP requests has the biggest impact on reducing response time. The percentage of users with an empty cache for different web pages may vary, especially for pages with a high number of active (daily) users. However, we found in our study that regardless of usage patterns, the percentage of page views with an empty cache is always ~20%. I found this really informative and a little surprising (especially since I think most people who use Yahoo use it on a fairly frequent basis.) On a related note: I did some testing with Yslow a few months back and I noticed that it does not always correctly report what is cached and what is not. It's been the primary reason why I've avoided trusting it blindly when optimizing pages. This happened when we introduced full image caching on one of our heavy-traffic sites. I was struggling for quite a while when it seemed that no matter what we did, not all stuff got cached, according to Yslow. Turning Yslow off and using a web proxy (Charles) to check for traffic we noticed that actually the images were cached as they should, although Yslow reported otherwise. I could investigate this a bit more and provide a demo page when I find the time for that. Of course the numbers above where propably generated from server logs so they should be correct - and equally alarming. Just a heads up. -- Suni
[jQuery] Re: JQuery Size YUI Compressor mod_deflate/GZIP
Good point! So what's the benchmark on Jquery script execution time using a YUI Compressed script versus packed jquery-1.2.2.pack.js? If the time is significant, then you're right - it probably makes sense to use the larger YUI-Compressed file instead of the smaller packed file. I feel like I'm on some super duper web optimization team ;-) Now if only I was good looking and cool...
[jQuery] Re: JQuery Size YUI Compressor mod_deflate/GZIP
Haha, you cracked me up :) I'm not sure of the figures for processing the packed version, however this would need to be done for every page of your site that the user visits because the JS is cached in packed form. This means that whatever the overhead is for unpacking the packed version, the delay is applied to every page of your site. For this reason, even if the regular minified (non-packed) version was even a bit larger than it is, I'd definitely lean towards using it as this can be cached once and used without delay on all subsequent pages. Joel Birch - member of the good-looking, cool, super-duper web optimisation team. :D
[jQuery] Re: JQuery Size YUI Compressor mod_deflate/GZIP
All this info - and more - can be found here: http://jst.pbwiki.com/summary.php --John On Jan 29, 2008 5:38 PM, Geoff Millikan [EMAIL PROTECTED] wrote: Good point! So what's the benchmark on Jquery script execution time using a YUI Compressed script versus packed jquery-1.2.2.pack.js? If the time is significant, then you're right - it probably makes sense to use the larger YUI-Compressed file instead of the smaller packed file. I feel like I'm on some super duper web optimization team ;-) Now if only I was good looking and cool...
[jQuery] Re: JQuery Size YUI Compressor mod_deflate/GZIP
Perfect. Thanks John!
