[wp-hackers] Packing JavaScript

[howard chen]

I think it would be design a build system for all these compression
stuffs - you might also be interested in compression CSS (use CSS
Tidy) or HTML compression (Template level)

On 9/18/07, Otto <otto at ottodestruct.com> wrote:
> 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
> >
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>