httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Millikan" <>
Subject RE: [users@httpd] mod_deflate and chunked encoding
Date Tue, 31 May 2011 11:27:19 GMT
> Goal is to get the HEAD of HTML documents in the client side as soon
> as possible ...thus having a more responsive page...


> Can anyone confirm or deny this...


I ran a quick test on a 10MB file that looks like this:

<link rel="stylesheet" href="broken_link_here.css" type="text/css">
About 15 megabytes of dummy ascii text here...

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 " 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.

Happy chunking,

Geoff @

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message