But all those features can be implemented efficiently. There are a lot of things that Nginx does not support, that would make Nginx slower if it did support that. .htaccess support for example.
This may be arguing semantics, but I don't consider that a feature, as anything doable via .htaccess is doable via the main config. (not to mention that nginx supports graceful hot reloads so it's not a problem to manually force it to rescan the main config.
The WordPress Supercache plugin automatically sets up a .htaccess with mod_rewrite rules to enable caching. On Apache, it just works. On Nginx without .htaccess support it would have to tell the user to copy-paste a snippet. Ouch, not so friendly. And this is even assuming the user has access to the web server config file.
In my experience, switching to a properly configured NGINX server running PHP-FPM with memcached negates much of the need for Supercache to begin with. Caching plugins tend to cause subtle problems all over the place for WordPress plugins, so I prefer to run "bare metal" as much as I can.
Also, I can't imagine anyone running NGINX without having access to the config file.
Actually, WP Supercache and nginx can form an awesome team.
You configure WPS to spit out gzipped copies of each page on disk, then you configure nginx to serve gzipped pages directly whenever they are found (gzip_static and try_files).
Basically you can serve compressed pages straight off disk. And thanks to the miracle of operating system file caching, it's usually straight from memory.
I completely agree with this and anyway many of the caching programs are starting to understand that nginx is out there. I am pretty sure w3 total cache does.
However since using nginx I have done away with caching as it is so much faster than apache + caching that I don't really need it.
That's my point. For any small/medium sites, switching to NGNIX will make a dramatic improvement on all aspects of your site, while dicking around with caching will cause you endless headaches.
