[wp-hackers] Packing JavaScript

[Alex Günsche]

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