在Yahoo系的最佳实践里，建议把静态的内容尽早的输出，在head之后就调用flush，让浏览器可以尽早去加载静态资源，包括脚本、样式、图片（javascipt，css，image一般是外链的形式）等等，后台如果有多个数据源或者api需要调用，尽可能做到完成一个输出一个，通过js在前端拼装页面，进而达到优化用户体验的效果，用户等待的时间，是木桶最短的那快木板。
下面是引用：
Flush the Buffer Early
tag: server
When users request a page, it can take anywhere from 200 to 500ms for the backend server to stitch together the HTML page. During this time, the browser is idle as it waits for the data to arrive. In PHP you have the function flush(). It allows you to send your partially ready HTML response to the browser so that the browser can start fetching components while your backend is busy with the rest of the HTML page. The benefit is mainly seen on busy backends or light frontends.
A good place to consider flushing is right after the HEAD because the HTML for the head is usually easier to produce and it allows you to include any CSS and JavaScript files for the browser to start fetching in parallel while the backend is still processing.
Example:
...
php flush(); ?>
...
Facebook提出的BigPipe技术，将这种思想有了更具体的实现，大体思路是，分解网页成叫做Pagelets的小块，然后通过Web服务器和浏览器建立管道并管理他们在不同阶段的运行。
在php下做个小测试，
';ob_flush();flush();sleep(2);echo "b";?>
结果可以看到在ie下（7，8），不管输出内容的大小，都可以看到效果，“b“在2秒后输出，在firefox和chrome，两段文本都在2秒后展现，说明浏览器做了缓存，经过实验，缓存的大小为1024，刚好1k，也是浏览器做的优化。通过返回头可以看出，在分段输出的时候，返回包没有经过gzip。
通过wireshark可以看到后台输出确实是一个个chunked过来的，看来是浏览器做了工作，猜测：缓存大小应该是1024B或者MTU大小（1400B多点，看网络情况），首段输出增大到1024的时，chrome和firefox都开始正常表演了，页面里的js、css和图片在第一段下载完已经开始加载。
应该思考的问题：
1、传输效率，尽量利用一次传输传送尽量多的东西，根据MTU大小调整；
2、同步加载，第一块送过来的东西，尽量可以同步加载，需要注意不同浏览器可以同步加载域名的数量，需要考虑javascript对加载的block，对于不用立刻执行的内容，可以通过加defer或者干脆注释掉，等页面完成在eval进来；
3、适用范围，任何一个技术都有自己适用的场景，对于后台需要访问多个api的应用会更适合一些，像社交类的网站，搜索之类的本来就在100ms左右就展现完毕，纯玩儿技术就没意义了，chunked也不是分的越多越好，适当的，类似的最好合并起来；
4、ob_flush和flush最好结对使用，某些情况下，当用flush是没有效果的。
参考：
http://www.BkJia.com/kf/201202/118114.html
http://developer.yahoo.com/performance/rules.html#flush
http://www.BkJia.com/kf/201202/118116.html
http://www.BkJia.com/kf/201202/118117.html
http://baike.baidu.com/view/4601904.htm
http://www.BkJia.com/kf/201202/118118.html
