This is a reply to an old thread that I just learned about: On Wed, 13 Aug 2008 09:42:42 -0700 Mark Lundquist wrote: > I guess a JS reader could be helpful for applications where all resources are served directly by "raw" Cocoon, i.e. if any compression is to be done then Cocoon has to do it. But don't most applications in a Web setting run Cocoon behind an Apache front-end? Then you can just have Apache gzip whatever you want, all outside of Cocoon, right? And wouldn't that take care of whatever one might want to gain from using a special compressing/"minifying" component for a specific resource type?
Mark, I wanted to respond as I've just been reading up on this. If you run the CompressorRater [1], it gives a very useful comparison of how JS changes in size, with and without minification and gzipping. With the js I put in, the YUI-compressed-and-gzipped code was a little over 1/3 the size of the gzipped-only code: Original code: 46425 bytes YUI compressed: 16922 gzip only: 15192 YUI compressed and gzipped: 5645 So no, there *is* very significant benefit to minifying, even if you're already gzipping. (All this aside from the issue of minifying at runtime vs. build time.) > > I could be totally wrong about this, but that's just how it seemed to me... anyway, is the use case for this specifically the scenario where un-Apache-front-ended Cocoon is being used to serve resources directly? I think this is an important use case too... it was our case for a long time, during which our Cocoon did have an Apache front end but we didn't control it. It was managed in another state, and the admin was too busy to enable on-the-fly gzipping. Regards, Lars [1] http://compressorrater.thruhere.net/ > > cheers, > —ml— > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
