[darsoli]

I think the main takeaway, caching, is important. But what's frustrating with Wordpress is that there are many plugins to do caching, and each caching plugin has a million options in it. How they handle images, dynamic content, cache headers, ETags, etc, are often buried deep in submenus.

On top of that, testing caching is challenging - replicating between local, staging, and prod is ultimately a very manual and error prone process, so there's no real way to figure out how to test and if what you're doing is the right thing. Since caching is not an immediate thing (it can take time for a CDN to pick up an asset, for example), it can be unclear if what you've done works, or if you need to wait five minutes and try again.

I wrote a blogpost a few months ago about this and other issues. (https://solitaired.com/why-we-switched-from-wordpress-to-nod...)

Maybe I'm doing it wrong? ¯\_(ツ)_/¯

[ehnto]

A Full Page Cache is the way to go, you're going to run into far fewer edge cases and cache bugs. For something simple like a blog, you shouldn't be hitting PHP at all once the cache is warmed, let alone caching queries and snippets and whatnot, bugs waiting to happen.

The strategy is the same even for complex sites, full page cache at the server daemon for almost every page hit unless a user is doing an action that isn't "View this page".

Obviously I'm glossing over cache busting strategies and how you handle dynamic actions like add to carts, sessions etc, but they're all far more simple than rolling your own application level caching strategy.

You will get so much more out of your hosting if using an FPC, which gives you way more headroom for the requests that do need to spin up the application.

[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.

[hawkoy]

You should use cloudfront, cloudflare or some similar service. They take care of caching your assets as well and I think are more trustworthy than some random caching plugin on wordpress.

Edit: I see you mentioning cloudfront on your blog post, what problems did you encounter when using it with wordpress?

Also, any reason for not using sanic, strapi or any of the headless CMS and building from scratch?

[darsoli]

For Cloudfront, I eventually got it working. The difficult part was figuring out how to get Wordpress to serve the site when it received the request from Cloudfront. By default, it turned into a weird redirect loop.

I eventually solved it by futzing with all the options.

Re why I didn't use Strapi/the others? Once I switched to node / markdown, I told myself I'd fit in a real CMS, but never got that far researching it. However, I like the options you mentioned. Thanks for sharing!

[innocenat]

I have not used cloudfront, but cloudflare significantly increase my TTFB.