cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Huttar <>
Subject Re: Proposal - JS Reader
Date Wed, 09 Sep 2009 11:37:39 GMT
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.



> cheers,
> —ml—

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message