Pre-compressed (gzip) HTML using fastcgi_cache?

Lucas Rolff lucas at lucasrolff.com
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: https://forum.nginx.org/read.php?2,270604,270647#msg-270647
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx



More information about the nginx mailing list