RE: Performance implications of Bundling and Minification on HTTP/1.1

Patrick,

We used the default static file compression in IIS -- I don't know off the top of my head what the parameter settings are but I can find out. Are you thinking of externalizing the compression dictionary and reuse it across resources? When I looked at compression many years ago we did look at external dictionaries but if I remember correctly it is only identified by a 32 bit CRC so it is not very unique. The challenge here is that this effectively makes compression a hop-by-hop mechanism which can have a much higher cost if you have intermediaries in the chain.

Thanks,

Henrik

[1] http://www.iis.net/ConfigReference/system.webServer/httpCompression


-----Original Message-----
From: Patrick McManus [mailto:pmcmanus@mozilla.com] 
Sent: Monday, June 25, 2012 10:48 AM
To: ietf-http-wg@w3.org
Subject: Re: Performance implications of Bundling and Minification on HTTP/1.1

Henirk, 

Thanks for the blog post! I've got a couple questions that came to mind.. I'll just put the gzip one in this post.

" our data shows that compression works better on a bundled document due to the larger size and hence the opportunity for better compression ratio. 

Compressing 7 JS individually 161178 bytes Compressing the minified JS bundle 137817 bytes

[.. redacted more or less the same for css ..] "

what about compressing the concat'd 7 js files and therefore extending the compression context across resource boundaries? Also, what was window size?

SPDY actually dropped a data-compression option in the transport (instead it uses resource level compression and makes support of that mandatory), but if there is reason to suggest significantly better rates doing it that way rather than per-resource then that's probably an interesting property to move along as we discuss http/2 (independent of whether it is implicit in a bundle or layered on as part of the transport). You could even imagine a small array of content-specific contexts (one for headers, one for js, one for html, whatever)..

Received on Monday, 25 June 2012 20:13:44 UTC