WebPagetest Forums
Start Render Time - Printable Version

+- WebPagetest Forums (https://www.webpagetest.org/forums)
+-- Forum: Web Performance (/forumdisplay.php?fid=3)
+--- Forum: Discuss Test Results (/forumdisplay.php?fid=4)
+--- Thread: Start Render Time (/showthread.php?tid=246)

Pages: 1 2 3 4 5 6

RE: Start Render Time - pmeenan - 06-15-2010 07:57 AM

If you don't want to overhaul the layout you can stay with the table layout but switch to a fixed layout and specify the dimensions (though if you are overhauling and modernizing the site, switching to a css-positioned layout is a good idea).

RE: Start Render Time - jarrod1937 - 06-15-2010 08:32 AM

(06-15-2010 07:57 AM)pmeenan Wrote:  If you don't want to overhaul the layout you can stay with the table layout but switch to a fixed layout and specify the dimensions (though if you are overhauling and modernizing the site, switching to a css-positioned layout is a good idea).
Yeah, i'll probably change it to use divs. Its the only thing that is using tables at this point, if i remember correctly, and is generated by the product listing module. So its easy enough to simply change the module's output and have it change all over the site. Though i am not sure how to do an arbitrary amount of products stacked on top of each other, with three per row, using div's, but i'm sure i can figure it out.

RE: Start Render Time - jklein - 06-16-2010 11:59 PM

On additional note on the subject of tables: Marissa Mayer from Google gave a talk last year at Velocity saying that "tables are purely evil" since the browser needs to wait for the closed table tag before it can start rendering anything. You can view her talk and get more information here:


RE: Start Render Time - jarrod1937 - 06-17-2010 11:00 AM

Thanks, that video is quite helpful. Though after looking at the code that is generating the product listings i am not sure if i can fit in changing it all to a div based layout by my deadline, it seems that the code will have to be completely redone to work with a div based output scheme. However, it looks like i can still get around that in a similar way google did, splitting a table into multiple tables so that the output is rendered in table chunks rather than one large table. I already experimented with specifying exact table and cell dimensions and that has indeed helped with the start render time, even with a table layout.
However, i've been researching and see that chunked encoding may enable progressive web page rendering through outputting the html doc as its being generated. This way one could output the entire head block, allowing the download to start for items in the head like the main .css file, while still processing the lower half and outputting that when done. This is something that could definitely help speed up the start render time. However, what little info i can find about it says that it should be enabled by default in apache, yet looking at my http headers i see no mention chunked encoding. Do you know of any info pertaining to enabling chunked encoding if it isn't enabled? I also wonder if its compatible with gzip encoding, it could be that mod_gzip is buffering the output for encoding and thus prevents chunked output. I also messed with php's flush command, which should have a similar effect, but also got no results.

RE: Start Render Time - pmeenan - 06-17-2010 11:55 AM

Do you control the server or are you on shared hosting? I haven't had much luck getting it to work on my shared hosting provider but it worked fine on a stand-alone install of apache 2.2 with mod_php.

For chunked encoding to be useful you need to flush the document out early from whatever code you are using to generate the pages (php from the sound of it). Then there's the matter of getting it to actually work through all of the parts of the server pipeline. Recent builds of Apache and mod_deflate both work with chunked encoding but it'll probably take a far bit of experimentation to get it working. They both go hand-in hand and it doesn't help unless you do both (in php you need more than just flush(), you need to look at ob_flush as well.

What it will buy you is reducing the time to first byte on the base page (assuming the time to generate the page and make your back-end calls is not insignificant) which will help with all of your other times.

RE: Start Render Time - jarrod1937 - 06-17-2010 12:40 PM

I have full control of the servers so i should be able to get it working no matter what configurations are needed. Though with php i thought ob_flush was only needed if you were manually buffering the output in php, but i'll keep that in mind just in case it is needed.
I've run page generation times in the past and found that most pages take around ~0.095 seconds but some a bit longer (aka 0.13 or so) to generate for a category page with 50 products. So there is some benefit to be had, though i can try to optimize the backend code to generate the page faster, but when you're dealing with 50 products per page it gets a bit tough, though small changes do scale nicely in such situations due to a small performance increase being 50 fold.
At what point in page generation speed do you think it wouldn't be that beneficial or would be negligible to use chunked encoding? Currently the average page generation time is about 20% that of the average time to first byte.

RE: Start Render Time - pmeenan - 06-18-2010 10:38 PM

Since you control the servers the only reason NOT to do it would be if you need to be able to modify the response headers later in the page (setting cookies, etc) since that becomes unavailable once you flush.

Stoyan has a little bit of a write-up with a few things to check here: http://www.phpied.com/progressive-rendering-via-multiple-flushes/

It could be that a lot of people disabled deflate and used php's output buffering to do the gzip compression (when they couldn't get it working on shared hosting).

RE: Start Render Time - jarrod1937 - 06-20-2010 12:15 AM


With the use of maxcdn, the extra domains/subdomains and properly maxing out the connections between them i was able to get the start render time to 1.287 seconds and the page load time of 1.980 seconds. Thats a pretty good number considering the page i've been testing is our site's average worst case, where they load up a category with at least 50 products showing.
As for progressive render, if you look at the waterfall i think the php flushing is actually working. The main html doc hadn't completely loaded, yet the .css file was requested from the cdn. To me this is good enough and a reason not to implement server-level chunking as I personally prefer the granularity of flushing output to the user in the application. This way i can try to flush the output at more optimal times than the server might.
On a random note, is there a way to speed up the initial connections? Or is it mostly just network delay that i can't help?

RE: Start Render Time - pmeenan - 06-20-2010 07:46 AM

Initial connections are all network propagation and short of actually distributing your front-end servers there's not much you can do to speed it up. A CDN makes the connections for static objects faster by putting hosts physically close to the user (speed of light problem, that's the only solution).

The flushing is actually not working from the looks of it (but it would be worth getting it working). The browser will always start parsing the html as soon as it starts coming in which is what you are seeing but what an early flush will get you is it will reduce that first byte time significantly (theoretically could get to be as fast as the connect time but in practice it will always be a little longer).

If you don't see the chunked encoding in the header then the early flush didn't work. The reason is that without chunked encoding the web server needs to know the full size of the response before sending it (and as a result, nothing gets flushed until the whole response is ready). With chunked encoding it can stream the response as it's ready (allowing for early flushing).

Nice work btw, the progress is great.

RE: Start Render Time - jarrod1937 - 06-20-2010 10:13 AM

Oh i see. Well in that case i have to admit i am stuck. Again what little info i can find says that chunked encoding should be enabled by default. Yet it doesn't matter what type of application level flushing (tried every method i could find) nothing happens. Though some things may be working against the use of chunked encoding. For one we're using the zues load balancer/reverse proxy software, which should support chunked encoding but who knows. Then we have an older version of apache, we still have yet to move to apache 2 due to other dependencies, though from what i've read our version should still support chunked encoding. I guess i'll have to investigate everything within the chain and make sure.
On a side note, i believe google is using chunked encoding/flushing their output earlier on, and while i see that no content length header is sent in their case i still do not see a chunked encoding header being sent by them either. You sure the header is necessary for chunked encoding or just that no content length needs to be given so that the output can be streamed?