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.