> Goal is to get the HEAD of HTML documents in the client side as soon > as possible ...thus having a more responsive page...
Agreed! > Can anyone confirm or deny this... +1 I ran a quick test on a 10MB file that looks like this: <html><head> <link rel="stylesheet" href="broken_link_here.css" type="text/css"> </head> <body> About 15 megabytes of dummy ascii text here... </body></html> And my FF4 browser didn't seem to try to load the css in the <head> area until the whole page finished inflating. My test showed (according to Firebug) that the 15 MB page downloaded in 618ms. The request for the style sheet *started* 4.39 seconds after the initial 15 MB page request stared. In other words, it took FF4 about 4 seconds to inflate the 15MB page, and then figure out that the <head> section required looking up of additional resources. Below are the response headers showing gzip with chunked. What we've found is that on lengthy pages like this, sometimes it's advantageous to the User to not DEFLATE because although the overall download time of the parent is slower, they experience what appears to be a faster page load time because the browser can start rendering the page as soon as it receives the first chunk (and also start requesting any additional resources that are in the <head>). But some of this is good web design too (like don't put your whole web page in a <table> because most browsers cannot start rendering the table until they hit the closing </table> tag). Date: Tue, 31 May 2011 11:09:31 GMT Server: Apache Last-Modified: Tue, 31 May 2011 11:08:02 GMT Expires: Mon, 06 Jun 2011 11:09:31 GMT Vary: Accept-Encoding Content-Encoding: gzip Keep-Alive: timeout=3, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html > ...or point to authoritative sources? Stabbing in the dark: The link below *seems* to say that the "inflate" job running in the web browser has "...no flush variable, since inflate() can tell from the zlib stream itself when the stream is complete." In other words it seems like the "inflate" job in the web browser cannot flush it's progress out (like the <head></head> part of the web page) until it gets to the end of the whole stream/file. It goes on to say, "If end-of-file is reached before the compressed data self-terminates, then the compressed data is incomplete and an error is returned." But all the zip/unzip programs I've worked with will flush their progress out as they work so this makes no sense. http://www.zlib.net/zlib_how.html Happy chunking, Geoff @ http://www.t1shopper.com/ --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
