[wp-hackers] Re: Packing JavaScript

Christian Höltje docwhat+list.wp.hackers at gerf.org
Wed Sep 19 00:41:27 GMT 2007

* Otto (otto at ottodestruct.com) [070918 14:48]:
> On 9/18/07, Charles <lists07 at wiltgen.net> wrote:
> > Another plus is speed benefits for end users.
> Compressed javascript is slower for end users, because you have the
> extra overhead of unpacking the javascript.

Uhm...no, that's not true.  The compression and decompression times
can actually (and quite often) equal less than the time gained in
sending the file.

> > JavaScript compression complements generic text compression nicely.  I use
> > "SetOutputFilter DEFLATE", and that works very well.
> I doubt that the minimal difference between packed JS and unpacked JS,
> given than both are being compressed using zlib, is highly
> significant.

It can be.  The next goal for YUICompressor is to optimizing the
variable substitution to allow zlib to compress the file even further.
Generally, packing the JS helps some, the amount depends on how the
packing is done.

> > Anyway, the combination of (1) JavaScript compression, (2) generic
> > server-side text compression and (3) file-combining is the norm, not the
> > exception, for sites that uses JavaScript for anything more serious than
> > roll-overs.
> 1 and 3 are useless in most (not all, mind you) cases. Whether it's
> the "norm" or not is debatable and largely opinion unless you can
> actually prove it with statistics. But whether they add a significant
> difference or not can actually be measured through testing. I submit
> that adding 1 and 3 to 2 will not produce a significant difference
> from just 2 alone.

Just curious, have you tried any of these things out yourself?
Because what you're saying isn't true.


"Smoke me a Kipper, I'll be back for breakfast"
		--"Ace" Rimmer (Red Dwarf)

The Doctor What: Kaboom!                         http://docwhat.gerf.org/
docwhat *at* gerf *dot* org                                        KF6VNC

More information about the wp-hackers mailing list