Effects of gzip_comp_level on HTML: Tweaking Nginx's GZIP settings

posted 2012-Jan-30
— updated 2012-Jan-31

The Nginx GZIP Module allows you to specify the compression level—trading off CPU time compressing versus network bandwidth—by setting gzip_comp_level to a value of 1 through 9. The following graph shows the effects of the nine different compression levels:

Graph Showing Benefits

Each line represents the effects on a different HTML file. As we can see, large files tend to compress better as a percentage of the overall size, particularly on files with repetitive content. (The largest two files were the lists of all objects (42k) and properties (462k) in ObjJob, which have many items with similar markup.)

There are only small gains from each compression level above 1. Following is the table of file sizes and the original URLs from which they were obtained:

gzip_comp_level source source source source source
(off) 32,976 3,614 8,171 43,201 472,852
1 9,310 1,426 3,763 8,474 48,026
2 9,063 1,421 3,701 8,302 44,497
3 8,948 1,409 3,665 8,180 42,807
4 8,591 1,370 3,529 7,721 40,012
5 8,467 1,359 3,490 7,570 37,670
6 8,398 1,357 3,494 7,458 34,789
7 8,366 1,355 3,497 7,242 33,394
8 8,363 1,355 3,496 7,201 32,441
9 8,350 1,355 3,497 7,201 32,356

Based on these results, I’ve set my own server at gzip_comp_level 5;. I have plenty of CPU time to spare these days.

It would be interesting if someone were to perform this analysis and pair it with the actual CPU impact and processing time for the various settings.

Gavin Kistner
10:40PM ET
2012-Jan-30

FWIW, using gzip on the command line produces file sizes slightly smaller than gzip_comp_level 6, in a few of my tests.

net.mind details other résumé contact
Phrogz.net