[wp-hackers] Re: Packing JavaScript

[Alex Günsche]

On Wed, 2007-09-19 at 13:17 -0500, Otto wrote:
> For everybody who's not Alex, here's my main argument:

I take the liberty to reply anyway, but as I'm on your ignore list, it
won't bother you anyway. ;-)

> 1. GZIP type compression.
> Advantages:
> - Works on all hosts that WordPress works on, if you do it using PHP.
> - Provides way more improvement than anything else (>90%)
> - Works with all modern browsers.

I agree.

> Disadvantages:
> - Requires caching on the server side to eliminate extraneous CPU use
> (think of like WP-Cache for javascript).

Can be done.

> - Won't work with some older browsers, but these are like <1% of the
> total population of browsers.

There's fallback solutions like alternate contents (via "Vary" header).

> 2. Javascript compression.
> Advantages:
> - Compresses javascript in a way that will eliminate any need for any
> server work of any kind.
> - Can be made "safe" at the cost of making better optimizations.

I agree.

> Disadvantages:
> - Only provides a ~50% improvement.

Much better than nothing, on hosts where gzip is not an option.

> - Provides less than a 3% improvement if done in combination with GZIP
> like compression.
> - Adds extra maintenance overhead to the development side of things
> (have to maintain compressed and decompressed versions, have to keep
> them in sync, etc).

I agree.

> - Slows down client side processing by a measurable and non-trivial amount.

If you say it is measurable, then let's have some figures, please.

> 3. Combining multiple files into one
> Advantages:
> - Reduces HTTP overhead, which improves visible speed quite a bit for
> a large number of files.

Ok.

> Disadvantages:
> - Eliminates all the effects of browser caching. Now, instead of not
> downloading files it already has, the browser will get those files
> every time, since the file is combined with others. This can result in
> a substantial bandwidth *increase* if not done carefully and
> correctly.

You can still do caching, with some sort of versioning, similar to the
way it's already done in WP. One can e.g. combine different version in
an appended versions hash and/or use an ETag HTTP header (if the server
doesn't issue one automatically). I bet that the number of possible
permutations and resulting JS code amount is still smaller than what we
have now (just a guess). 

>  It's actually a deoptimization in many cases, and should be
> used only where it makes sense. TinyMCE uses it because it makes sense
> to do so there. It does not necessarily make sense in a global
> perspective.

I have to admit I don't understand why it would make sense for TinyMCE,
yet not for, let's say, the files in the wp-includes/ base directory.

Kind regards,
Alex

-- 
Alex Günsche, Zirona OpenSource-Consulting
Blogs: http://www.zirona.com/ | http://www.regularimpressions.net
PubKey for this address: http://www.zirona.com/misc/ag.ml2007.asc