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.

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.

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!

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.

This opens up for so much quick’n'dirty hacking that I am scared, but go ahead anyway!