Append Vary: Accept-Encoding for Static Content & W3TC

I am trying to append “Vary: Accept-Encoding” in header, specially for static content like image and js, css. By default EasyEngine turned this on by gzip very on; so in home page I see this returns perfectly “Vary: Accept-Encoding”.

But for static content it follows rule defined in locations.conf, which is

add_header “Access-Control-Allow-Origin” “*”;

So, I get this return for CURL for any static file

Access-Control-Allow-Origin: *

It does not matter what I configured in W3TC browser cache control policy for static content.

What am I doing wrong? is it supposed to be like that? What will the best practice if I want to append anything in header in EE system? as all files in common could get override after an update.

@Asif2BD Glad to see you are giving EasyEngine a try. :slight_smile:

It does not matter what I configured in W3TC browser cache control policy for static content.

W3TC setting generates a nginx config file which we are not using.

If possible, please edit locations.conf. ee update will not overwrite your changes.

Also, if you find anything EE shouldn’t be doing, please let us know.

By the way we are considering dropping support for W3TC/WP Super Cache completely in near future -

Also, today we are releasing a new redis full-page cache option which has performed much better in benchmarks. You may like to try redis cache.

Very interested to try redis cache. And will be able to use cdn too without W3TC. And I know we could achieve almost all caching just from nginx conf. BTW I am hugely pagespeed fan. So, should I try redis with pagespeed? with cdn setting from pagespeed?

If you are using a mirror CDN, like Amazon Cloudfront, you can add a line like below to nginx conf file for that site:


It will be better to add this line by opening conf file using a ee command

ee site edit


It doesn’t work well with fastcgi cache or newer redis-cache. Ref -

We did not try PageSpeed with W3TC cache but I doubt it will work with them as well.

So PageSpeed affects scalability for static sites as it wasn’t designed for static sites running full-page caches. We learned this late. :expressionless:

We are not using pagespeed internally for any sites. For css/js minify/combine, we use plugin.

Still, if you want to enable pagespeed, you can try it.

I am using pagespeed with W3TC, with SSL via EE at

I was able to reduce my payload from 2.5MB+ to now just 165KB, and page load time dropped from 5 sec+ to now just 593ms. All with EE, so very happy. Now getting over 90 in GTMetrix for PS & YS.

I am willing to try redis, I have a test machine with EE. BTW I have not got good result so far on Autoptimize on any project, it looks good from ourside, but not even comparable with pagespeed. The on the fly image convert to webp is super cool, and does not put much stain on CPU or RAM.

@rahul286 what about sending up favicons, etc that are in say the wp root location? does subs_filter take more than one mapping? Or items that appear in styles.css?

Sorry to highjack this topic, Rahul could you clarify I thought that FastCGI (WPFC) is for full page cache and REDIS is for object caching usually used to cache WP backend. How this REDIS full-page cache works? Will cache both front-end and back end or only front end? I’m currently using FastCGI (–wpfc) for full-page cache and Redis (via Redis Object Cache plugin) for backend caching.


Redis cache feature is just released. Please check -

About pagespeed - it might work with lot of tweaking. Here is a workaround suggested by pagespeed dev -

You can use regex or multiple subs_filter.

subs_filter is different than sub_filter module. (please not s at the end of sub) (user this one)

Using nginx modules :slight_smile:

You may like to check -

May I know which redis object-cache plugin you are using currently ?

I’m using Redis Object Cache by Till (

It’s rock solid and supports HHVM’s Redis extension, the PCEL Redis Extension and the Predis library for PHP.