[snowwrestler]

When I self-hosted Wordpress sites, we put Varnish on the same server and ran traffic through there. Varnish has a reporting feature that lets you track the hit ratio in near real-time, so we could change a cache setting and see its effect on the ratio pretty quickly. We could purge the cache in whole or in part with the CLI.

We picked whatever the most popular cache plugin was at the time and turned on the default settings, then went from there. Honestly, the difference between any caching strategy and no caching strategy can be huge, especially when you get a surge of traffic.

We put staging behind the cache too, but not local or dev. Staging was just to test that a caching configuration change would not take the site down. A bunch of the tuning was actually done on production and back-ported to staging.

I think a hidden factor here is what people know. If a person/team knows node.js really well and doesn't know Varnish, then of course it's going to seem easier to move to node. That seems pretty common to me; it's more like web development, whereas caching/Varnish seems more on the sysadmin side of things. My team had to learn it, which took a little while.

But in my experience, well-tuned caching in front of WP can scale really well for content that changes rarely like blog posts or articles.

Today we pay WP Engine take care of it all for us and it's money well-spent.

[falcolas]

Varnish cache is great. Heck, any kind of caching is great. Even a stupidly simple 5 second cache will be sufficient for handling most levels of traffic.

[darsoli]

Ah, Varnish - I have heard so many great things. Not sure why I didn't use it this time around. I think I assumed Cloudfront would take care of it.

My biggest learning was that CDN != caching. While it can be used as such, it's not automatically set up that way out of the box.