Symphony.

Had a strange issue on my site (www.educatorshandbook.com) for some time. For pages created with symphony, the DOMContentLoaded event does not fire until nearly 5 seconds after the last visible activity in my Firebug Net panel. I don’t have this problem on any of my subdomains not running symphony cms.

I searched the forums, but didn’t see anything like this reported. Anyone have any ideas?

In FF 3.5.8 I’m getting an error from the ga.js script: “cannot access optimized closure”.

Hmmm… Googling up the ga.js error indicates it is not a problem. Just to be sure, I removed the analytics code from the page (back in now) and tried again - same problem, so it doesn’t look like an analytics issue.

Any ideas?

For that matter, disabling javascript in safari or firefox doesn’t seem to affect the issue at all, so it doesn’t seem to be a js issue.

The only info I think you’d get from Symphony would be the profiler times, beyond that I’d imagine its an environment issue. Good luck!

For that matter, disabling javascript in safari or firefox doesn’t seem to affect the issue at all, so it doesn’t seem to be a js issue.

If you’re disabling JavaScript, how are you testing when DOMContentLoaded has fired? Are you able to throw up a test page for us to look at? Perhaps an identical page on two hosts, one Symphony and another not.

Okay. Have a test page:

Symphony generated page: www.educatorshandbook.com

Static page: www.educatorshandbook.com/static.html

Although the content loads quickly, I am getting about a five second difference. Here is the output of the Full Page Render Statistics from that page (which doesn’t look strange to me):

Total Database Queries  53
Slow Queries (> 0.09s)  0
Total Time Spent on Queries 0.0150 s
Time Triggering All Events  0 s
Time Running All Data Sources   0.0615 s
XML Generation Function 0.0022 s
XSLT Generation 0.0110 s
Output Creation Time    0.1152 s
Total Memory Usage  1.05 MB

@austinjackson That application were built on Symphony? Looks great.

Those are quick page generation times. The output is sent back to the client at a similarly quick speed (within a second) so I’m not sure why DOMContentLoaded is taking those extra seconds.

HTML

Symphony

The only different I can think of are the difference in headers, causing the browser to slow down?

The strange thing in my tests is that the DOMContentLoaded event fires always after exactly the same amount of time (4.49s in Firefox, 5.01s in Webkit).

Here is something interesting. Both of Nick’s firebug screenshots list the html file as being 2.2k, but when you look at the headers, the symphony generated page has a much longer Content-Length header set.

Symphony: Content-Length 6079 Static: Content-Length 2288

Where in the symphony code are these headers set? Maybe the browser is waiting on additional content before it fires the onload event?

@rainerborene Thanks! The site is Symphony. The software it advertises is not.

Amazing.

Commenting out line 22 in index.php solved the problem:

header(sprintf(‘Content-Length: %d’, strlen($output)));

Should I report this as an issue?

Out of curiosity, for those of us who don’t know, what does that line do, exactly? What purpose does it serve?

I’d be ready to go drop it on my sites if it’s a possible speed bump but I want to know what I’m killing before I do.

what does that line do, exactly? What purpose does it serve?

That line tells the browser, ahead of time, how big the page it is about to receive will be. That way it can stop reading as soon as that value is reached, and know it has everything. Instead of waiting until it thinks it has everything.

Maybe the browser is waiting on additional content before it fires the onload event?

That is likely the case.

header(sprintf(‘Content-Length: %d’, strlen($output)));

strlen() returns the number of characters, but Content-Length expects the number of bytes. Normally this will work, since 1 ASCII character = 1 byte, however if the site displays multi-byte characters, the strlen() value will be wrong. However, that would result in a smaller content-length, rather than a larger one.

I think this should be submitted as an issue. It will require some proper testing.

@dougoftheabaci I don’t think the Content-Length header is required, but as Alistair mentions, it is supposed to speed up rendering times by giving the browser more information about what it is receiving. In my case, it seems it was telling the browser that the content it was sending was 3 times LONGER than it actually was, which was causing the browser to wait for the data it was told to expect.

I don’t think the Content-Length header is required

I think it actually should be there. See here:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html (section 14.13)

That’s interesting:

In addition, browsers using HTTP/1.0 to communicate with the server can only use “Keep-Alive” connections if they have the “Content-Length” header. These are desirable as they can considerably reduce page-loading latency.

(http://www.edginet.org/techie/website/http.html)

however if the site displays multi-byte characters, the strlen() value will be wrong. However, that would result in a smaller content-length, rather than a larger one.

Maybe mb_strlen would solve this?

Maybe mb_strlen would solve this?

There’s still the problem that it might not be available on all systems (PHP must be compiled with the --enable-mbstring flag).

But it seems the problem here is that the Content-Length header is too long, rather than too short. Could this be due to an incompatibility with gzip or deflate compression?

I can not reproduce this issue, although I am running a 2.0.7 website with gzip. My server (Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny4 with Suhosin-Patch) is sending the correct content-length for the compressed page.

Could it be that your server is somehow configured to not overwrite content-length headers for gzipped pages (and so the original header gets through)?

Could you switch off gzip compression and see how it goes? Would be an interesting test.