WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#6524 closed defect (bug) (fixed)

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

Reported by: Toolskyn Owned by:
Milestone: 2.5.1 Priority: low
Severity: normal Version: 2.5
Component: TinyMCE Keywords: has-patch
Focuses: Cc:

Description

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

Attachments (2)

6524.patch (721 bytes) - added by azaozz 6 years ago.
6524.2.patch (588 bytes) - added by azaozz 6 years ago.
OK, removing content-length

Download all attachments as: .zip

Change History (9)

comment:1 azaozz6 years ago

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.

comment:2 Toolskyn6 years ago

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.

comment:3 azaozz6 years ago

  • Keywords has-patch added

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.

azaozz6 years ago

comment:4 matt6 years ago

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

azaozz6 years ago

OK, removing content-length

comment:5 azaozz6 years ago

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.

comment:6 ryan6 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:7 ryan6 years ago

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

Note: See TracTickets for help on using tickets.