Current time: 12-15-2017, 06:30 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Start Render Time
07-14-2010, 08:59 PM (This post was last modified: 07-14-2010 09:00 PM by green-watch.org.)
Post: #51
RE: Start Render Time
Hey Guys,

I have been reading over this post to try to learn about the start render time and how to lower the value to make things appear faster.

Quote:By definition the browser can't render anything until it has received something from the server so TTFB on the base page is critical to start render but not the only contributor. It needs to completely parse the head and then calculate the layout before anything can show up on the screen.

So it sounds like having little in the head as possible is a great way to reduce the start render time. So this would mean JavaScript would be better suited at the end of the body as opposed to the head section (even if it is asynchronous calls). Why do I always see it being encouraged to have JavaScript in the head?

Looks like I can play around with flushing and perhaps get everything above my header displayed quicker.

Sincerely,
Travis Walters
Find all posts by this user
Quote this message in a reply
07-14-2010, 10:20 PM
Post: #52
RE: Start Render Time
(07-14-2010 08:59 PM)green-watch.org Wrote:  So it sounds like having little in the head as possible is a great way to reduce the start render time. So this would mean JavaScript would be better suited at the end of the body as opposed to the head section (even if it is asynchronous calls). Why do I always see it being encouraged to have JavaScript in the head?

Yep - it's even a YSlow rule: http://developer.yahoo.com/performance/r...#js_bottom :-)

You do have to be careful about dependencies for inline code though. It's "easier" to have it in the head because you can guarantee that the code is loaded before any inline javascript on the page is executed.
Visit this user's website Find all posts by this user
Quote this message in a reply
07-14-2010, 11:42 PM
Post: #53
RE: Start Render Time
(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 am curious how the players such as Google/Yahoo/etc have implemented their early flush strategies. If anyone has any links/info I'm all ears. Big Grin

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.
Find all posts by this user
Quote this message in a reply
07-15-2010, 12:15 AM
Post: #54
RE: Start Render Time
(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.
Find all posts by this user
Quote this message in a reply
07-15-2010, 04:35 AM
Post: #55
RE: Start Render Time
Here is a link to the Yahoo presentation that mentions it. http://assets.en.oreilly.com/1/event/44/...tation.pdf

it is about 2/3rds of the way down, no video I'm afraid. I was disappointed by the lack of video for a lot of the talks at Velocity, my biggest criticism for the 2nd year running. There is so much good stuff being said at the same time that its impossible to see everything.

I didn't know about setting the charset in the response headers. I shall have to investigate :-)
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)