[wp-hackers] Packing JavaScript

[Otto]

While I see the benefits of the idea, I'm not sure how useful it will
actually be in this particular case. Looking at the SVN:
-jQuery is already packed code.
-TinyMCE gets gzip compressed if the browser supports it (examine
tiny_mce_gzip.php).
-There's various pre-made packed versions of Prototype and
Scriptaculous if you need them, best to use those instead of rolling
your own. Or better yet, wrap them into gzip.

And so on. These javascript compression methods just always strike me
as a bit silly. You'd be better off creating a static *.gz version of
the file and having the web server serve that directly. Of course,
that's only "easy" with either Apache 1.3 and mod_gzip or Apache 2.2
and mod_deflate+mod_filter, but still, it's more of a server thing.

Essentially what I'm saying is that the WordPress package should
really only include a) pre-packed versions of code from the actual
code providers, or b) some easy way to configure it to use server
features for compression.

Actually distributing packed versions in the core just seems like a
bad idea in the long run. It's modifying these standard libraries, and
while it might not break core code, it could break plugins wanting to
use those libraries and which are expecting them to work like the
originals do, without fail.


On 9/18/07, Alex Günsche <ag.ml2007 at zirona.com> wrote:
> Hi all,
>
> WordPress comes with tons of JavaScript by default. Regardless of any
> server-based compression, it's always a big bunch of bytes to download.
> Ok, most of it is in the admin backend, but still, I think there's a
> possiliblity for optimizazion -- especially if you think of WPMU
> communities.
>
> Some of you might know the nice JS packer by Dean Edwards [1], e.g. used
> by MooTools [2] by default. It is a very clever tool to "compress"
> JavaScript files to 30-70 percent of the original size.
>
> I have made some tests on my WordPress installs, one is WP 2.0.11, the
> other is 2.3-beta3.
>
> With a little shell foo, you'll find out the amount of JS code in the WP
> core:
>
> sum=0; for j in $(for i in $(find ./wp-admin/ ./wp-includes/ -iname "*\.js"); do du -b $i | cut -f 1; done); do sum=$[ $sum+$j ]; done; echo $sum
>
> The outcome is: 357642 bytes for WP 2.0.11 and 1020175 bytes (!) for WP
> 2.3-beta3.
>
> Now I've taken the php5 version of the packer [3] to test it on the JS
> files in the WP core. I extracted the package to WP_ROOT/jspacker/ and
> uncommented the argv section in example-file.php. Then I ran the
> following:
>
> for i in $(find ./wp-admin/ ./wp-includes/ -iname "*\.js" | sed 's|\.js$||'); do cp $i.js $i.src.js; php ./jspacker/example-file.php $i.src.js $i.js; done
>
> Running the first command line again (the sum stuff) and subtracting the
> results from the respective previous results (because it also counts the
> new/copied src files) shows that the compressed JS files now make a
> total of 195703 bytes (2.0.11) and 562329 bytes (2.3-beta3). This is
> about 50% of the total size saved.
>
> Now the big question is: Does it break the JS? It is to say, that in
> rare cases, the packer can break JS code. And indeed, some short tests
> on both versions showed the following:
>
> - Most JS, including the remote stuff, works as expected.
> - On 2.0.11, TinyMCE seemed not to be able to initialize, so WP came
> with the fallback editor, though that one worked.
> - On 2.3-beta3, TinyMCE works fine, though switching between Visual and
> Code doesn't work.
>
> In Firefox, the web developer toolbar shows some errors with the syntax
> in the packed files, which explain the above problems.
>
> Bottomline so far: There is a possibility for much optimization in the
> size of JS downloads. There are some minor problems, which can be solved
> though (e.g.: fix files manually, not compress files that seem to break,
> fix packer).
>
> Now one can even imagine to go one step further: I find it also annoying
> that one has to download so many files. In theory, it would be better to
> pack all JS into *one* big file and let the UA download that one. This
> would significantly reduce the number of HTTP requests.
>
> Of course, I wouldn't want to merge TinyMCE, Prototype and all the other
> JS in one file in the source distribution, but one could imagine having
> a backend JS handler that gathers all JS files to be inserted and
> delivers them as one. We do have API hooks for JS (at least in the
> admin), so it wouldn't be too hard to gather the files.
>
> It's even possible to imagine a global on-the-fly packer combined with a
> JS cache, which could again bring additional performance.
>
> Just some ideas ... what do you guys think?
>
> Kind regards,
> Alex
>
> [1] http://dean.edwards.name/packer/
> [2] http://mootools.net/download
> [3] http://joliclic.free.fr/php/javascript-packer/en/
>
> --
> 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
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>