Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

I use Redmine with Passenger and Nginx. I'm just wondering if there are any reasons to use gzip on option?

As I understand the CPU usage will be increased if I set this option on, but the users with slow internet connection get the pages faster.

But may be there are any recommendation or testes which help me to make the right decision.

share|improve this question
up vote 3 down vote accepted

The good question should sound like: "Is there any reasons to NOT use ngx_http_gzip_module". No, there isn't.

gzip_comp_level 1; gives a rather good compression ratio on text while CPU utilization stays low. So, even users with a fast Internet connection in terms of last mile will get the pages faster.

Google recommends to Use compression to make the web faster.

share|improve this answer

Using compression, your CPU usage will be higher, but your bandwidth utilization will be lower. If you're paying for bandwidth by the gigabyte (and many of us do) then this will benefit you as well.

@ChrisS makes good recommendations, but I'll expand on them a bit:

  • Static content that is already highly compressed, such as audio and video files, doesn't really benefit from gzip encoding, so there's no reason to waste your CPU trying to compress them again.
  • Static text-based content such as CSS and JavaScript files can be easily compressed, and nginx can handle this easily. Use gzip on for these content types.
  • Dynamically generated content should be gzip compressed by the web application instead of nginx, as it has a much better idea of whether the content should be compressed or not.
share|improve this answer
Actually nginx has builtin facilities to do smart decision regarding compression. You don't need to re-implement all that logic on the application level. – VBart Jul 20 '12 at 18:12


  • dynamic content gzip off
  • static content that's:
    • easily compressed (html, css, js, xml) gzip on
    • not easily compressed (graphics, audio, video) gzip off.
share|improve this answer
Strange answer. Dynamic compression gzip on exists especially for dynamic content. For static there's gzip_static on in nginx. – VBart Jul 20 '12 at 15:14
I'm not actually very familiar with nginx, this answer just applies to HTTPd compression in general. – Chris S Jul 20 '12 at 17:04
And, as you wrote, dynamic content should not use compression? Why? Even this page is compressed. – VBart Jul 20 '12 at 17:21
It's a generic statement, so take it with a grain of salt. The web server doesn't know the makeup of the dynamic content, so it wouldn't know if it should be compressible or not. Also, the web server would have to compress every single page, which chews up more CPU resources than you'd think. This site isn't actually dynamically generated, each page is intelligently cached instead. It's a fine line, but there are real distinctions when the cached copy can be cached compressed, thus eliminating the necessity of compressing the page every time it's delivered. – Chris S Jul 20 '12 at 18:59
But you can tell the web server what should be compressed and what not by configuration, and it's easier than implement such logic in application. I also know that in future versions of nginx its cache will be able to compress stored data on the fly, and re-compress with better ratio in background. – VBart Jul 20 '12 at 19:15

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.