mod_deflate vs mod_gzip

Question

Can someone tell me the difference in the following scripts in terms of CPU load performance and compression?

<ifModule mod_gzip.c> 
mod_gzip_on Yes 
mod_gzip_dechunk Yes 
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$ 
mod_gzip_item_include handler ^cgi-script$ mod_gzip_item_include mime ^text/.* 
mod_gzip_item_include mime ^application/x-javascript.* 
mod_gzip_item_exclude mime ^image/.* 
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.* 
</ifModule> 


<ifModule mod_deflate.c> 
<filesMatch "\.(js|css)$"> SetOutputFilter DEFLATE </filesMatch> 
</ifModule> 

Kopaz

possible duplicate of Why use deflate instead of gzip for text files served by Apache? – Ratib

possible duplicate of mod_deflate or mod_gzip, which should be used? – Ahab

Answer 1

Both these modules do the same thing: add gzip compression on the fly.

The one you should use these days is mod_deflate - it is the more modern and recommended one and is distributed with Apache. mod_gzip was an older third-party implementation and there is no good reason to use it anymore.

Don't be fooled by the names into thinking they use different compression schemes. They both use gzip (which is a format that uses a compression algorithm called DEFLATE). The latter is only called mod_deflate because the name mod_gzip was taken. They both will achieve the same compression levels with equivalent settings.

They have different configuration (which may include different default settings) so you need to find documentation for the specific one you're using.

Karlsbad

After a few years and some chatter, finally someone posts an actual answer to the OP. – Wist

Answer 2

I guess you're asking about the differences between these two, and not about compression in general. In that case, I recommend to use mod_deflate which relies on the still-active project zlib. BTW, old articles (6-7 years old) that compare the two, are not relevant anymore.

Something

Answer 3

Most compression algorithms, when applied to a plain-text file, can reduce its size by 70% or more, depending on the content in the file. When using compression algorithms, the difference between standard and maximum compression levels is small, especially when you consider the extra CPU time necessary to process these extra compression passes. This is quite important when dynamically compressing Web content. Most software content compression techniques use a compression level of 6 (out of 9 levels) to conserve CPU cycles. The file size difference between level 6 and level 9 is usually so small as to be not worth the extra time involved.

For files identified as text/.* MIME types, compression can be applied to the file prior to placing it on the wire. This simultaneously reduces the number of bytes transferred and improves performance. Testing also has shown that Microsoft Office and PostScipt files can be GZIP-encoded for transport by the compression modules.

Some important MIME types that cannot be GZIP encoded are external JavaScript files, PDF files and image files. The problem with Javascript files mainly is due to bugs in browser software, as these files are really text files and overall performance would benefit by being compressed for transport. PDF and image files already are compressed, and attempting to compress them again simply makes them larger and leads to potential rendering issues with browsers.

Prior to sending a compressed file to a client, it is vital that the server ensures the client receiving the data correctly understands and renders the compressed format. Browsers that understand compressed content send a variation of the following client request headers:

Accept-encoding: gzip

Accept-encoding: gzip, deflate 

Current major browsers include some variation of this message with every request they send. If the server sees the header and chooses to provide compressed content, it should respond with the server response header:

For more information, see this article: http://www.linuxjournal.com/article/6802

Trailblazer

This answer provides a lot of useful information but doesn't address the question at all: Which is a better choice, and why? – Prendergast

This copy-and-paste job doesn't even attempt to answer the actual question. I don't know why it's been received positively. – Karlsbad

Answer 4

Enabling mod_deflate and mod_gzip basically accomplishes the same thing, they both compress your web files before they get sent to the visitors of your website.

There are differences between the two though; mod_deflate can sometimes have a slighter better compression percentage as mod_gzip. Another reason you should choose mod_deflate is because it's better supported as mod_gzip which makes it easier to configure because it's better documented. More info can be found here.

Cocytus

Answer 5

Check out this article on linuxjournal.com

http://www.linuxjournal.com/article/6802

Other than that mod_deflate is easier to configure and generally comes along the apache package.

Auger

Answer 6

IMHO You should avoid using mod_deflate for static files, instead serve precompressed files through mod_rewrite with best compression available (7zip created gzip AFAIK). Apache is not caching gzipped static files.

For dynamic files: depends on available bandwidth - mod_deflate needs lot of processing power, but usable if your server is capable of overflowing your network.

Saito

-1 Your answer is opinion based & has nothing quantifiable to support that opinion. You would need to weigh up the pros & cons depending on your use case. – Lipsey

I think my comment states obvious things. Apache can serve about 10 times more files when serving static precompressed files. And You can save about 10% bandwith as 7zip creates smaller zip files then gzip. You will have a bit better response time as well without gzipping. And You are wasting resources to zip the same static files over and over again. Overall mod_deflate is a fine module, but use only for dynamic files. – Saito