Comments on: Quick and dirty test of the YUI Compressor

By: Jørn Thøgersen

Jørn Thøgersen — Mon, 03 Aug 2009 11:58:49 +0000

I think it should make a difference as we have many .js files for the sake of overview as we are several developers working on the same rather large project. So one big file in our case should minimize network overhead. The question is how effective this trade off between number of files and ‘large file download’ is.

For now I am buried in other work as I have just returned from holiday but it is worth a quick and dirty try when I catch up with my pending tasks.

By: kamstrup

kamstrup — Thu, 30 Jul 2009 07:35:46 +0000

I am wondering whether it would make sense to roll up all linked .js and .css files into big catenated files? And maybe also do js-mangling on these files.

It would be an attempt to minimize the number of network roundtrips the browser has to do to load the page. I just checked that Firefox 3.5 (at least) does not have HTTP pipelining enabled by default, which means the browser must do a HTTP GET for each linked file.

Anyways – just a thought.

By: Jørn Thøgersen

Jørn Thøgersen — Fri, 03 Jul 2009 11:08:25 +0000

Yes the load times should only be effected the first time before the cache kicks in. Actually I just tried it out and the load times the second time around are nearly the same with the minified and normal version. The minified version is a tiny bit faster but probably nothing that would be noticed by the user and not near the half a second that was shaved off the first time you load the page with the minified version.

We do have a lot of home grown JS and rely on Prototype (we are in the process of switching to JQuery) for the rest. I agree that there is a small risk for errors and actually I have had a lot of compressor errors with the jscalendar-1.0 library. As long as obfuscation is not used I still think that this is a small issue as it is easy to disable/enable the compressor and/or exclude certain problematic files.

It’s a good point that the extra layer of complexity vs the ‘one time only effect’ may turn out to be not worth the hassle. We haven’t concluded anything yet but are in midst of trying different things out and seeing what will yield the most benefit compared to the implementation effort needed.

Thanks for your comment!

By: jrochkind

jrochkind — Thu, 02 Jul 2009 13:46:59 +0000

That should really only effect load times the FIRST time a user visits your site, because after that their browser should have the JS cached—true? I’d be interested to learn if my assumption there is incorrect, or if you’ve tested it yourself too, first load vs. subsequent loads.

The only downside I see is some additional complication in debugging, and the possibiilty that the compressor may introduce bugs (although I’d assume that’s a pretty small risk). But just generally having another layer to deal with and debug. If you aren’t writing your own JS but only using third party JS libraries that are reasonably mature and tested, perhaps this is less of an issue.

But personally, based on my assumption that it only would effect the first un-cached page view (not that that’s not important too, it is, but balanced overall…) vs having another layer in my environment to effect debugging and stuff, I’ve never pursued that compression stuff.