Announcing Stack Overflow Documentation



Sign up and start helping → Learn more about Documentation →

What advantages do either method offer for html, css and javascript files served by a LAMP server. Are there better alternatives?

The server provides information to a map application using Json, so a high volume of small files.

See also Is there any performance hit involved in choosing gzip over deflate for http compression?

share|improve this question
switched accepted answers... the current consensus is two to one in favour of gzip – Ken Oct 2 '12 at 21:15
mod_deflate is for Apache 2, mod_gzip is for Apache 1.3. – SPRBRN Oct 17 '14 at 12:30
up vote 257 down vote accepted

Why use deflate instead of gzip for text files served by Apache?

The simple answer is don't.

RFC 2616 defines deflate as:


The zlib format is defined in RFC 1950 as :

     0   1
     |CMF|FLG|   (more-->)

       0   1   2   3
     |     DICTID    |   (more-->)

     |...compressed data...|    ADLER32    |

So, a few headers and an ADLER32 checksum

RFC 2616 defines gzip as:

gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.

RFC 1952 defines the compressed data as:

The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods.

CRC-32 is slower than ADLER32

Compared to a cyclic redundancy check of the same length, it trades reliability for speed (preferring the latter).

So ... we have 2 compression mechanisms that use the same algorithm for compression, but a different algorithm for headers and checksum.

Now, the underlying TCP packets are already pretty reliable, so the issue here is not Adler 32 vs CRC-32 that GZIP uses.

Turns out many browsers over the years implemented an incorrect deflate algorithm. Instead of expecting the zlib header in RFC 1950 they simply expected the compressed payload. Similarly various web servers made the same mistake.

So, over the years browsers started implementing a fuzzy logic deflate implementation, they try for zlib header and adler checksum, if that fails they try for payload.

The result of having complex logic like that is that it is often broken. Verve Studio have a user contributed test section that show how bad the situation is.

For example: deflate works in Safari 4.0 but is broken in Safari 5.1, it also always has issues on IE.

So, best thing to do is avoid deflate altogether, the minor speed boost (due to adler 32) is not worth the risk of broken payloads.

share|improve this answer
Shouldn't there be a new standard that combines adler32 with gzip? – Pacerier Jul 4 '12 at 2:14
Your URI is broken. – Reut Sharabani Mar 29 at 8:11

GZip is simply deflate plus a checksum and header/footer. Deflate is faster, though, as I learned the hard way.

gzip vs deflate graph

share|improve this answer
Not to mention that zlib doesn't have support for the extension, and even if it did, the CRC32 instruction in SSE 4.2 uses the polynomial 1EDC6F41, and the gzip format uses the polynomial EDB88320 - totally different algorithms, effectively. – Jack Lloyd Oct 20 '09 at 15:59
And since deflate is faster, why is SO using gzip? – David Murdoch Sep 16 '10 at 12:51
Well, this answer turns out to be incorrect ... see: zoompf.com/blog/2012/02/lose-the-wait-http-compression ... in particular client have 2 ways they can "interpret" deflate, headerless/checksumless and with zlib header. The implementation across browsers of a correct deflate is bad. deflate should be avoided. – Sam Saffron Mar 24 '12 at 23:36
@sam additionally I just re-ran the benchmarks and on a modern Intel chip, I get gzip 1441/692 and deflate 1286/531. Second number is decompress, first is compress. So deflate is still faster, do your benchmarks show otherwise? (I agree it may not be useful for other reasons, but the answer is correct, deflate is faster..) – Jeff Atwood Mar 27 '12 at 7:04
@JeffAtwood but the question wasn't faster? – Ken May 15 '12 at 21:44

You are likely not able to actually pick deflate as an option. Contrary to what you may expect mod_deflate is not using deflate but gzip. So while most of the points made are valid it likely is not relevant for most.

share|improve this answer

The main reason is that deflate is faster to encode than gzip and on a busy server that might make a difference. With static pages it's a different question, since they can easily be pre-compressed once.

share|improve this answer
presumably with gzip you can't start transmitting the header until you've obtained, stored and compressed all the data? (because you need the checksum to create the header) – OJW Jun 30 '09 at 11:25
In the gzip format, the checksum comes at the end of the file, specifically so one can start writing deflate blocks as they are processed without having to hold everything up. – Jack Lloyd Oct 20 '09 at 16:00

I think there's no big difference between deflate and gzip, because gzip basically is just a header wrapped around deflate (see RFCs 1951 and 1952).

share|improve this answer

mod_deflate requires fewer resources on your server, although you may pay a small penalty in terms of the amount of compression.

If you are serving many small files, I'd recommend benchmarking and load testing your compressed and uncompressed solutions - you may find some cases where enabling compression will not result in savings.

share|improve this answer

There shouldn't be any difference in gzip & deflate for decompression. Gzip is just deflate with a few dozen byte header wrapped around it including a checksum. The checksum is the reason for the slower compression. However when you're precompressing zillions of files you want those checksums as a sanity check in your filesystem. In addition you can utilize commandline tools to get stats on the file. For our site we are precompressing a ton of static data (the entire open directory, 13,000 games, autocomplete for millions of keywords, etc.) and we are ranked 95% faster than all websites by Alexa. Faxo Search. However, we do utilize a home grown proprietary web server. Apache/mod_deflate just didn't cut it. When those files are compressed into the filesystem not only do you take a hit for your file with the minimum filesystem block size but all the unnecessary overhead in managing the file in the filesystem that the webserver could care less about. Your concerns should be total disk footprint and access/decompression time and secondarily speed in being able to get this data precompressed. The footprint is important because even though disk space is cheap you want as much as possible to fit in the cache.

share|improve this answer
GZip probably checks the checksum on decompression, hence the speed difference for decompression. – Seun Osewa Nov 5 '09 at 8:02

Just for future reference:

Under a debian system (I'm on ubuntu) with Apache2 and the deflate module already installed (which it is by default), you can enable deflate compression in two easy steps:

a2enmod deflate
/etc/init.d/apache2 force-reload

And you're away! I found pages I served over my adsl connection loaded MUCH faster!

share|improve this answer
Except that that enables gzip, since mod_deflate confusingly implements only gzip compression... – Gert van den Berg Jul 24 '14 at 10:38

if I remember correctly

  • gzip will compress a little more than deflate
  • deflate is more efficient
share|improve this answer
gzip is deflate with a header. And HTTP 1.1 deflate is actually zlib (which is also a wrapper around deflate) – David Murdoch Oct 20 '09 at 19:14

Your Answer


