[whatwg] HTML resource packages

Diego Perini diego.perini at gmail.com
Wed Aug 4 17:34:03 PDT 2010

2010/8/4 Kornel Lesiński <kornel at geekhood.net>

> On 4 Aug 2010, at 11:46, Diego Perini wrote:
> > > * Argument: What about incremental rendering?
> > > If there are, for instance, lots of (content) images in the resource
> file I will see them all at once as soon as the ZIP has been downloaded
> completely and decompressed, but with single files I would have seen them
> appear one after the other, which might have been enough.
> >
> > ZIP files are progressively renderable, dependant on file order.
> >
> > In my experience "gzip" compression is blocking browser rendering until
> the compressed file has been received completely.
> >
> > I believe this is the reason we should not compress the HTML source, just
> its external binary components.
> >
> > I don't think the browser can separately decompress each block of a
> chunked transfer as it arrives, am I wrong ?
> You are wrong. gzip compression is streamable and browsers can uncompress
> parts of gzipped file as it is downloaded. gzip only needs to buffer some
> data before returning uncompressed chunk, but it's only few KB. Chunks of
> gzipped data don't have to align with chunked HTTP encoding (those are
> independent layers).
Tank you for the informations and correcting my statements. I just tried and
definitely "chunked" and "gzip" compression can happen at the same time.

The problem is I have a strange effect on my pages if I enable Apache
"SetOutputFilter DEFLATE", the pages progress and rendering are different.

It works well with "zlib.output_compression", more or less with no visible
changes from non compressed. I will have to dig what makes this difference.

Diego Perini

> --
> regards, Kornel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100805/894ea201/attachment-0002.htm>

More information about the whatwg mailing list