EDIT: I'm not saying these softwares can't do more, it's just that usually on most default configurations, people don't bother to use a CDN, optimize the database, use a caching plugin, etc. They just install it, then install another 39 plugins and then ask why everything is slow. It's very common to see WordPress websites failing under load (and I've helped many to optimize their installs so I know it's possible, it's just not what the average WordPress install looks like).
I used to have a 5mil pageviews per month site running on 5$ instance from DigitalOcean
I have known teams move to back to very simple default wordpress hosting from more advanced stacks.
My point is it harder to get your marketing dept to upgrade tech even if we could do it.
I have learnt over the years that solutions that have to be for the people who will use everyday, even if it's poorly managed WordPress.
In your example You or your SRE/devops will do all the basic configuration tunning pretty much out of the box. Your IT dept may not be able to at all or unless someone tells them to
It meant that we -never- had naked requests hitting the underlying CMS, so our security footprint there was miniscule (to access it you'd need to already be in the network), there was no chance of failure (i.e., even with a caching layer, a bunch of updates and enough traffic could lead to a spike hitting the CMS, and in fact, if there was a bad edit in the CMS that lead to part of the site being malformed, the crawler would die, alerting us to the bad edits before going live), and we could host using any static site/CDN we wanted to, with the only downside being deploys took a while. Even that downside we could have worked around, if we'd wanted to get into the CMS internals enough to track modifications; we just really didn't want to.
I was tempted to building something like like you did, but came to the same conclusion many do : it is not our core business and marketing will still have issues as the offering won't be as good as a professional one.
Even a solution to bridge the two setups needs dev time to maintain. End of the day managed solutions like Hubspot comes in cheaper in total cost of ownership even though all of this kind of architecture is technically superior.
The move for us was before netlify became popular so never could consider it.
That's why I was tempted to build, then I realized bulk of the work will be to build the graphical UI editor and templating tools - the parts I hate to begin with.
Awfully presumptive there aren't you. :P
I've had software solutions delivered by consultants in past jobs that were billed as being 'complete', that were missing that. 10 rps = Django fell over, site is down. That was the first thing we fixed.
[1] See, for example, https://ably.com/support , which is currently still up.
[2] The cf-cache-status header says "DYNAMIC", which means "This resource is not cached by default and there are no explicit settings configured to cache it."
I'm pretty sure cf-cache-status is added by CF—that's not the site saying not to cache it, it's CF reporting that it's not cached (which, again, I think is the default, not something the site owner deliberately turned off).
Need to use a "Page Rule" telling CF to cache everything, and provide the required Cache-Control header values from app side.
It's not an option in the caching settings (or need a enterprise plan?)
Enterprise is largely about very high levels of bandwidth use, serving non-Webpage traffic, and all kinds of advanced networking features. It's also a hell of a jump in price from the $200/m top-tier "self-serve" plan (which is also the only self-serve plan with any SLA whatsoever, so, the only one any business beyond the "just testing the waters" phase should be on)
But the Cache Settings page, it doesn't have the "Cache Everything" option, or it's reserved to Enterprise plan.
It's covered in what I'd consider to be one of a handful of docs pages that're must-read for most any level of usage of the service:
https://support.cloudflare.com/hc/en-us/articles/200172516-U...
(it also links to a page that describes exactly how to create a "cache everything" page rule)
Then again, most orgs have a ton of stuff they ought to do and haven't gotten around to. You just hope it doesn't bite you quite so publicly and ironically as this.
If you're going to make a big deal about being contrarian with your technological choices, you either have to be really good at what you do, or be really honest about what tradeoffs you're making. I'd be extremely embarrassed if I pushed this blog post out.
I was serving static HTML off a $5 VPN and later off Cloudflare Pages. The response times were stable in both cases for all users.
I’m no WP expert but maybe they have a good reason to leave caching out of the core.
Unpatched WP instances full of vulns are also rampant for this reason.
Now, application servers and database tiers, that's a different story. Epic novel, really.