Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Having played with several web servers online, I've seen things such as goDaddy not enabling gzip by default. Same with a few IIS drops, default installs of apache, and so forth.

I keep running across servers that don't have basic things that improve your website speed turned on by default.

This leads me to two options: everyone who makes webserves packages it poorly, or I just don't understand why they've done this. It's much more likely that I don't know why they don't do this.

Could someone enlighten me as to why you would ship webservers with disabled features such as gzip, and various cache control headers?

I thought faster websites were a result of this, as per what ySlow and PageSpeed tell me all the time. What are the drawbacks?

share|improve this question

migrated from Aug 2 '11 at 17:44

This question came from our site for professional programmers interested in conceptual questions about software development.

Perhaps, I thought about it but I felt there was overlap with non-server based web technologies. – Incognito Aug 2 '11 at 16:33
I don't think this would be a constructive question on Server Fault. I'm not sure it's a constructive one here to be honest. – ChrisF Aug 2 '11 at 16:47
@ChrisF Could you be more specific? I'm asking what merits shipping software in a configuration without optimization offers. Specific to very popular techniques. Those techniques even have multiple tools designed specifically to measure quality. For something so seemingly important, why is it made against the grain? Do you truthfully feel there's nothing to learn here that is cannon to the website? – Incognito Aug 2 '11 at 17:16
@ChrisF It would be fine to have on ServerFault. Bring it on over, we'll take care of it. – Wesley Aug 2 '11 at 17:33
@ChrisF I've asked on the chat and the consensus is it belongs over there. Please migrate to ServerFault. Thanks. – Incognito Aug 2 '11 at 17:33
up vote 6 down vote accepted

"resources" - it takes ram & CPU to compress your content on the fly... a very little bit but resources nonetheless, on a site or two it's trivial, but on 1000 or more... things can get funky. Also - Falcon's comment is valid - vendors do want the failsafe 'bare bones' configuration as the default.


UPDATE: I forgot as well: the extra execution time on each request to do the actual compression also - there is the extra memory used by loading mod_deflate [deflate_module] in the first place, so generally every process gets a little bit fatter and a little bit slower. ~ like I say, generally trivial, but if you are strapped for resources to begin with....

share|improve this answer
I'd like to change that to "the false myth of server resources". Usually HTTP compression places a completely negligible load on modern servers. SSL, which can be an order of magnitude more CPU demanding than Gzip, is still often <5% of server CPU load. And besides, if there is an extreme case were some webserver is unable to Gzip compress due to CPU+RAM load, then either just place a caching proxy server in front of it, or pre-compress text content via a scheduled task (cron). – Jesper Mortensen Aug 2 '11 at 18:09

One reason could be IE6 compatibility. While IE6 supports gzip, it only does it up to 65535 bytes compressed size.

If your page is larger than that the rest will be cut off without explanation. But here's the funny part: It only happens if the page was loaded from file cache, not if it's received over the network, making the whole mess hard to debug.

It can be worked around by processing the headers of the request, but sometimes there will be a transparent proxy using IE6, eg. virus software. The proxy does not alter any User-Agent header so you're pretty much out of luck. Good thing that IE6 is almost eradicated.

Not sure if all versions were affected or only some, but the above was the reason the website I work for had gzip off for a long time.

share|improve this answer
agree with Tom, IE6 compatibility problems are a joke now. – GruffTech Aug 2 '11 at 22:41

You may think that it is because GZip is not supported by every browser. This explanation is wrong: a server can be backward compatible based on Accept-Encoding header of the request, which indicates whether the browser can accept GZip-compressed content.

A possible explanation is that there is no need to compress everything. Why would you compress a ZIP file, or a JPEG image? At best, the size will be the same. At worst, it will become larger.

Another factor is server-side performance. It is better to let the developer turn on compression when this developer knows the impact on the CPU and the pros and cons of ZGip for a specific content.

share|improve this answer
You're absolutely correct about not doubly compressing ZIP, JPEG etc; but this is fairly easy to avoid. All major webservers (at least IIS, Apache, nginx that I know of) have ways to control which content types (MIME types/extensions) may be compressed. – Jesper Mortensen Aug 2 '11 at 18:13
It's easier to include MIME types to compress than exclude MIME types to send without compression. If a person cares about compression, he would enable it; if a person don't care about it or don't know about it, it would stay enabled on types unknown by the server, decreasing server overall performance. – MainMa Aug 2 '11 at 18:23

I think it's for compatibility reasons. Some clients aren't able to decompress it and in some rare cases it can break server-side functionality. The vendors probably want a failsafe default configuration.

share|improve this answer
I don't think so: when making a request, a browser specifies if GZip is accepted (example: Accept-Encoding:gzip,deflate,sdch), which means that the server can GZip content only when it is supported and staying compatible. – MainMa Aug 2 '11 at 16:07

The less instructions a web server needs to execute the more requests it can serve.

gzip compression takes instructions to execute, so it slows it down. If you want it you can turn it on.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.