Chunked Transfer Encoding vs Content-Length

Hello WPT! Recently I’ve been researching on the difference between chunked transfer encoding vs content-length. I’ve learned that in chunked transfer encoding, the page is rendered as soon as the first bytes are received, whereas in content-length, it must wait for everything to be downloaded before rendering the page.

Perception is reality. Clearly, chunked transfer encoding would be the winner here. However, I also learned that it has quite a bit of overhead and for large pages, you don’t have control of how big each chunk is going to be. I noticed this very site uses nginx and all pages are served with chunked transfer-encoding.

Does anyone have more insights on this? I would love to hear more from you guys. Currently I use lighttpd with defined content length. The pages don’t render until all bytes are received, which does feel slower compare some other sites that uses chunked encoding.

Here is my latest test result: http://www.webpagetest.org/result/120712_ZP_9W2/1/details/

According to the last post, I haven’t said very much, but:

http://www.webpagetest.org/forums/showthread.php?tid=10748

One thing to note up front. The browser will kick off the css before the whole html is received (which on FIOS is near instantaneous of course). I ran a 56k test to illustrate this. (http://www.webpagetest.org/result/120712_E8_32302128697dd7274cecb6caee5bf278/1/details/) Notice that the css is requested before the html has finished downloading.

That’s just an aside. Chunking can be enormously beneficial - when coupled with careful flushing. Stoyan (as usual) writes this up beautifully:

This might significantly reduce the TTFB (but that is only 100-150ms)