Improving TinyMCE editor performance

[Javer]

This patch uses TinyMCE compressor for composing all TinyMCE javascript-files into single file, gzipping it and send to client with cache options. This greatly improves performance by decreasing requests count and bandwidth needed for loading all TinyMCE scripts.
Without patch: 11 requests to TinyMCE scripts with overall size 343 Kb.
With patch: 2 requests (independent to count of used plugins) with overall size 66 Kb. It is necessary to create /cache directory with access mode 777, which can be used in the future for caching other engine scripts and/or css, for example.

[till]

I am assigning this to Eric for review.

A general comment, I see the numbers, but afaik compressing JavaScript? code is not always to the advantage. Yes, less to download, on the other hand, more processing "power" is needed for the JavaScript? interpreter (in the browser) to work with the compressed file.

But this is just a general note/concern - I am gonna settle for what the experts think!

[till]

Also, the savvy administrator wouldn't "chmod 777". ;)

[memoryhole]

Replying to till:

A general comment, I see the numbers, but afaik compressing JavaScript? code is not always to the advantage. Yes, less to download, on the other hand, more processing "power" is needed for the JavaScript? interpreter (in the browser) to work with the compressed file.

I think it's worth pointing out that there's two kinds of JavaScript? compression: minifying and gzipping.

Minifying is really just removing unnecessary stuff like whitespace and some brackets (http://en.wikipedia.org/wiki/Minify); surprisingly, this can actually reduce the size of the code significantly. It takes no more processing power on the interpreter's part to work with it, because it's syntactically identical to the original. So, it cannot hurt performance, it can only improve it. The only downside is that it makes the code hard to read (which is obviously only important to developers who need to debug it).

Using *gzip* does cost some, though, you're right. But I think it's a case of relative costs. If your javascript is just a few bytes, then the cost of decompressing it is relatively much larger than the cost of executing it. However, if the JavaScript? is big enough and compression saves a fair bit of space, the cost of decompression is relatively insignificant and can be more-than made up for by the savings in download time. However, if your computer is so slow that decompression takes longer than downloading the full-size script, obviously it's not a good idea. In-memory decompression, though, is generally pretty fast, even on pretty old computers. I think TinyMCE is probably big enough for gzipping to be a win for virtually everyone.

[mpeel]

tinymce is definitely big enough to warrant gzipping it - although it might be easier just to set cache headers on the javascript files instead, and make them expire after 1/2/4 weeks instead?

[estadtherr]

Although their approach is novel (combine and compress the JS code on the server, unpack within the browser), it seems like they're re-inventing the wheel a little bit. The same improvement can be had by adding a single line to Apache's httpd.conf file (assuming mod_deflate is loaded):

 AddOutputFilterByType DEFLATE application/javascript

Any modern browser already supports (and asks for) gzip encoding, so why not just use the capabilities that are already there?

[estadtherr]

Closing - TinyMCE runtime JavaScript? is already "minified," and compression can be done by web server and browser with a simple configuration change (see my previous comment).