views:

3463

answers:

4

I just finished reading this post: http://developer.yahoo.com/performance/rules.html#flush and have already implemented a flush after the top portion of my page loads (head, css, top banner/search/nav).

Is there any performance hit in flushing? Is there such a thing as doing it too often? What are the best practices?

If I am going to hit an external API for data, would it make sense to flush before hand so that the user isn't waiting on that data to come back, and can at least get some data before hand?

Thanks to everyone in advance.

+3  A: 

Down side is that you can't gzip the content as well as flushing it afaik, so I've always preferred to gzip rather than flush.

"Some versions of Microsoft Internet Explorer will only start to display the page after they have received 256 bytes of output, so you may need to send extra whitespace before flushing to get those browsers to display the page."

This makes this not idea, as it seems padding more data isn't very useful.

Rich Bradshaw
I agree, however, most people have more meta data inside of their head tags than 256 chars. It's not really that much if you think about it.GZip is a good point though.
Cory Dee
+6  A: 

The technique described looks nice, but has several pitfalls:

1) the time between PHP script start and end is small compared to transmission time; also, this saves the user about 0.5 seconds, according to your source. Is that a significant amount of time for you?

2) this technique doesn't work with gzip output buffering

3) if you flush too often, you'll be sending an almost-empty packet on flush, which might actually increase loading time (on slow, noisy connections).

4) once you flush, you can't send any more headers

5) (minor issue) the server response will come in chunked encoding, which means the client won't know the size in advance (therefore won't display "x% done" when downloading a file).

On the other hand, if you expect your script to run for a loooong time (20+ seconds), it may be needed to send some data (spaces, for example) to keep the browser from timing out the connection.

Piskvor
+1  A: 

Following Piskvor's point - if you are expecting a 20s+ wait, you may be better off providing a basic page (which can be gzipped) and using Ajax to update the page when the slow process has finished. You do start to infringe the basic usefulness of static html, though.

Phil H
+2  A: 

I think flush is really a fine tuning mechanism. Browsers only use about 8 threads to download content (depends on the browser). If you have 15 images, the browser will start downloading 8 images and won't download anything else until one of them completes, then it will start downloading the next image, etc. By flushing after the header, you are basically telling the browser what it can start downloading. By the time the rest of the page is delivered (i.e. .5 seconds later), the browser may have already finished downloading the css and javascript files. This would free up download threads for other content.

You probably don't want to use flush in any other place than right after the header. A browser usually won't render unclosed html tags, so delivering a partial page won't display things any quicker. Older versions of IE won't display anything at all until a certain amount of data is received, or page delivery is complete.

Brent Baisley