2

Specifically I am working with IIS7, in case there are platform specific reasons, but I am curious in general.

I know gzip compression is more CPU intensive for both the server and the client, but it seems like the trade off for lower bandwidth would be overall a positive change since so much web content is highly compressable (thinking of HTML, CSS, and JS).

CoolUserName
  • 513
  • 2
  • 5
  • 9
  • @awoodland you're right, that does make more sense :) Should I delete and repost, or let the move-post gods do their handy work? –  Aug 19 '11 at 18:45
  • It's only one vote away from moving now, I think it would be better if it was moved so that Christian's answer doesn't get lost. I think you could flag and ask for it to be moved although I've already done that now. – Flexo Aug 19 '11 at 18:46
  • P.S. There's loads of other interesting Q&A sites in the network - http://stackexchange.com/sites – Flexo Aug 19 '11 at 18:49

2 Answers2

2

Compressing web content (via deflate or gzip) is a trade-off between CPU and bandwidth.

Generally speaking, the relatively low CPU investment in compression of the files is going to be of little to no impact; unless CPU is your bottleneck at all times (and, really, even if it is), compression is unlikely to have any tangible negative.

The positive is, of course, bandwidth freed up; while some content will compress much better than others, and some not at all, there's going to be at least a marginal reduction in bandwidth consumption with compression enabled.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
1

If files are sufficiently small gzipping them may be slower than sending them uncompressed.

  • Some info on size here: http://webmasters.stackexchange.com/questions/31750/what-is-recommended-minimum-object-size-for-gzip-performance-benefits – LosManos Mar 15 '13 at 08:35