[nextw33k]

Whenever I hear about HTTP compression I always think of Jeff Atwoods blog post: http://blog.codinghorror.com/youre-reading-the-worlds-most-d...

Basically DEFLATE beats GZip because its faster at decompressing. Choosing a compression scheme should be about balancing the transmission time with the decompression time, compression time is the least important aspect of the problem since caching can help mitigate that problem.

Statements like "This algorithm compresses better than gzip/deflate, at the expense of slower compression. Decompression is much faster than compression." mean nothing because its not telling you if the decompression time on a mobile device is worse than if you had sent it without compression. Plus I'd be surprised if there was any algorithm that was slower to decompress than it is to compress.

[qrmn]

I can't think of many scenarios in which this would be a win which aren't usually compressed archive downloads of some sort anyway, or might be better presented as a torrent with a tree hash and some multisourcing.

LZ4 might be a better choice. It compresses moderately well, but the packing and depacking speed are much better. Has anyone investigated whether it's viable?

Also don't forget that you need to be careful about compression in a few contexts where attacker-injected data and a secret could share a compression context (the BREACH attack, for example). Compression is usually a good idea, but you should really salt new CSRF tokens every load. HTTP/2's header compression is context-free to mitigate the related CRIME attack.