wp-includes/js/tinymce/tiny_mce_config.php very slow

[Toolskyn]

wp-includes/js/tinymce/tiny_mce_config.php gave problems in my installation. That file took almost 16 seconds to load.

After some debugging I found out that if I comment line 259:

header( 'Content-Length: ' . strlen($content) );

its loadtime was reduced extremely, back to a more normal value.

When I looked at the tiny_mce_config.php alone I could already see al content while it was still loading. So the browser was waiting for content while everything was already available. So it looks like the strlen($content) returns a value that is too large.

The browsers I used to test this were Firefox 3 beta 4, Safari 3.10 and Opera 9.23

[azaozz]

Toolskyn, can you provide some information about the web server you're using and if it's a local install (localhost). Also could you download the cached file /wp-content/uploads/js-cache/tinymce_[long number].gz and compare its size with what's returned in the header for content length. Thanks.

[Toolskyn]

I'm running an Ubuntu (gutsy) webserver (no localhost) with:

• Apache/2.2.4
• PHP/5.2.3 (- MySQL 5.0.45)

• Size of tinymce_[...].js : 236,868 bytes
• Size according to the header (using Firebug) : 236,868 octets

So that's the same. Still when I remove the Content-Length the loading-times are reduced to some normal value.

I looked at some other static files, and nothing goes wrong there. So I'm guessing it isn't my webserver config. I tried commenting the whole caching part of the file, and I noticed the page loading fast in that case.

[azaozz]

I couldn't reproduce it. Loading directly /wp-includes/js/tinymce/tiny_mce_config.php from a server with similar configuration averages at about 0.8 sec. with compression and server side caching disabled.

Also line 259 should run only once when TinyMCE's configuration is changed, after that the server side cache is saved and on the next load it should return header "HTTP/1.1 304 Not Modified" if caching in the browser is enabled.

Header "Content-length ..." is not essential. RFC 2616 lists it as "should use". It may help to speed things up, especially when there is high packet loss on the net.

On the other hand when TinyMCE is gzipped, the server sets header "Transfer-Encoding chunked" which ignores Content-length, so it's better to not send it at all in this case.

[matt]

This patch is weird, if it's not required why not just stop using it, rather than add more conditionals.

[azaozz]

OK, removing content-length

[azaozz]

I think I found out why it was slowing down: the compressor was detecting zlib.output_compression enabled, so it wasn't compressing it and was sending Content-length of the uncompressed file.

However the file was later compressed in the buffer, so the length was incorrect. Disabling Content-length fixes it. The second patch is the right one.

[ryan]

(In [7635]) Don't send content length for tinymce config. Props azaozz. fixes #6524 for trunk

[ryan]

(In [7636]) Don't send content length for tinymce config. Props azaozz. fixes #6524 for 2.5