- From: Diego Perini <diego.perini@gmail.com>
- Date: Thu, 5 Aug 2010 02:34:03 +0200
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-0001.htm>
Received on Wednesday, 4 August 2010 17:34:03 UTC