Start Render Time

[jarrod1937]

(07-14-2010 11:42 PM)calumfodder Wrote:  

(06-20-2010 12:39 PM)jarrod1937 Wrote:  I am not sure why this is, unzipping/uncompressing the file client side shouldn't be adding that much delay.
For now, i'm done tweaking for the night, we'll see if i can get both mod_gzip and chunk encoding working tomorrow. If not i may give mod_deflate a try, i believe its available even for older apache versions.

In tests I've done with flushing (was November last year) I've found that you need to be careful about the size of the initial chunk of html being sent down.

Each browser has a minimum amount of html code that needs to be received before it will start parsing the code(http://www.stevesouders.com/blog/2009/05...ent-early/ - see comment 8). So you may need to pad the initial chunk so that it will cater for the vagaries of the browser in order to initiate parsing (and get a head start in the downloading of extra resources).

A second quirk I found was that this minimum size seems to be an 'on the wire' size. E.g to take ie7 on webpagetest (needs 128B) the chunk would have to be 128B compressed size or 128B uncompressed size. I'm pretty sure I found the same behaviour on Firefox & Safari as well. So the efforts to pad a chunk to a minimum size may get borked by compressing the content sent to the browser, forcing you to perhaps add more padding than should be necessary. If you are using the php filter to do compression it would be interesting to see if you can send an initial chunk uncompressed, perhaps padded to 2KB size to capture chrome, and the rest of the chunks compressed...not sure how feasible that is.

I did end up padding the output at first, but in order to speed up my start render times i started adding more data in the head section before the first flush and eventually had enough data there that it wasn't necessary to pad it. I found that throwing in the .css file first (just after the doctype of course) greatly reduced my start render time as the .css file got downloaded long before the bulk of the page processing got started. I also added some dummy link tags that force some form of dns prefetching for all of the domains i'm using. All in all it added up to be around 530 bytes and compressed to be around 300 bytes (a lot of it is the doctype, which is xhtml so its kind of long). Though i wonder if comment #8 in that link is correct, 2KB for chrome is quite a requirement, and one must wonder if chrome in particular looks for 2KB of total payload, compressed/uncompressed, or not as you said. After a bit of searching though i found this:
http://www.kylescholz.com/blog/2010/01/p...arset.html

Which gives lower figures than previously reported. Their figures are still high but only if the char set http header is missing in the first place, if one is added through the http headers or through a http meta equivalent, buffering was decreased considerably.

(07-14-2010 11:42 PM)calumfodder Wrote:  An interesting point from Velocity this year was regarding rendering of a page and divs. It was mentioned that rendering would be blocked if the page was wrapped in a large root div and that removing the root div and having the page in smaller div sections allowed for the sections to be flushed individually and rendering to follow on. I haven't played with this yet. I'm not sure if it blocks the time to start render or whether it just blocks progressive rendering of the page.

Interesting, are there any presentation materials or videos from the conference online for that? Would be interested to look further into that.