Pre-compressed (gzip) HTML using fastcgi_cache?

Lucas Rolff lucas at
Sun Oct 30 09:49:35 UTC 2016

What you could do (I basically asked the same question 1 week ago), is 
that whenever you fastcgi_pass then enforce accept-encoding: gzip - 
meaning you'll always request gzipped content from your backend - then 
you can enable the gunzip directive by using "gunzip on;"

This means in case a client that does not support gzip compression, 
nginx will uncompress the file on the fly - where rest of the requests 
will be serving the file directly with a content-encoding: gzip - then 
the supporting client will automatically do whatever it should.

First of all it saves you a bunch of storage and it should give you the 
result you want. Serving (pre)compressed files to clients that support it.
Best Regards,
Lucas Rolff

seo010 wrote:
> Hi *B. R.*!
> Thanks a lot for the reply and information! The KEY however, does not
> contain different data from http_accept_encoding. When viewing the contents
> of the cache file it contains the exact same KEY for both MD5 hashes. Also,
> it does not matter what browser is used for the first request. For example,
> using a Google PageSpeed test at the first request will create the expected
> MD5 hash for the KEY, and a next request using Chrome will create a new hash
> for a file that contains the line "KEY: ..." that matches the KEY for the
> first MD5 hash.
> The third request also has a different KEY. I did not test any further, it
> may be that the KEY will change for every new client. The KEY does remain
> the same however for the same client. For example, the first request uses
> the MD5 hash as expected for the KEY (as generated by MD5) and it will keep
> using it in next requests.
> As gzip compression causes a huge overhead on servers with high traffic, I
> was wondering if Nginx would cache the gzip compressed result and if so, if
> there is a setting with a maximum cache size. It would however, cause a
> waste of cache space.
> In tests the overhead added 4 tot 10ms on a powerful server for every
> request compared with loading pre-compressed gzip HTML directly. It makes me
> wonder what will be the effect on servers with high traffic.
> As there appears to be no solution in Google, finding an answer may be
> helpful for a lot of websites and it will make Nginx the best option for
> full page cache.
> Best Regards,
> Jan Jaap
> Posted at Nginx Forum:,270604,270647#msg-270647
> _______________________________________________
> nginx mailing list
> nginx at

More information about the nginx mailing list