Check out Rob Howard’s response to this article, Rebuttal: The Case for Caching, and join the conversation on Twitter.
Back in 2005, before the iPhone, cell phone carriers charged a fortune for call time and text messaging. Because they could. This created all kinds of unusual workarounds by business owners to try and solve the “price gouging” imposed by a semi-monopolistic ecosystem (sound like the gas prices lately?)
One of these workarounds was the Nextel phone. It was an unholy merger between a cell phone and a walkie talkie, popular with contractors. Instead of using cell data, it was like talking on a private CB radio.
But frankly, this was an example of a solution to a problem that didn’t need to exist
If only the cell phone carriers hadn’t tried to milk their customers for every last dime over a resource that had (literally) zero incremental costs associated with allowing unlimited use.
Similarly, I find myself contemplating why, in 2022 we have “managed” WordPress hosting that has enabled caching by default and forced users into having to invent workarounds to solve what does not need to be a problem at all.
Today, nearly any WordPress site has at least one of four types of dynamic content: eCommerce, Marketing Automation, Membership, or Learning Management. On top of these are the dynamic conditional content displayed by Gutenberg and the other popular page builders based on the behavior of site visitors.
So why are many well known, profitable, and otherwise sensible WordPress hosting companies thumbing their noses at customers like the cell phone carriers did back in 2005?
Why are they charging a premium price for this disservice, yet calling it “managed” hosting?
Perhaps “managed” stands for…we “managed to make things harder for you than it could be” ?
Frankly, I know most of the founders of these hosting companies, and I don’t believe they have any malevolent intent. They are smart and caring human beings, trying to build a better product and service.
Instead, I think the problem is that someone hasn’t focused enough light on the problem to force them to change what may have been good practice ten years ago…but is no longer a good practice today.
These managed hosts force various caching methods (server, browser, object, cdn, ges) upon everyone, without the two critical options that would fix the problem immediately
- All caching should be disabled by default, with a notice in the WP dashboard
- All caching should have a WP dashboard control panel with a “kill switch”
First, all caching should be disabled by default, while displaying an admin notice in the WP dashboard that cache may be enabled after the site is ready to go live.
It’s pointless to have cache enabled by default. Think about how WP sites are created. They are literally blank slates, with no content or data or visitors upon launch. There is no reason for caching to be activated by default, when doing so causes so many problems during setup.
If you’re not familiar with these problems, they include such things as: page layouts not reflecting changes made in the page builder, courses that don’t reflect a user’s progress through the lessons, sales funnels and checkouts that don’t reflect what someone has purchased or has in their cart, users who see login messages even after they have logged-in, and more.
Second, all caching should have a WordPress dashboard control panel with a “kill switch” to disable caching at any time for testing or diagnosis. This should be on the WordPress site. It should not require one to log into the host, figure out how to get around two factor authentication (when the site admin and owner may be different people) and then dive six levels into the abyss of the hosting dashboard.
The majority of “managed” hosting customers are not technically trained. That’s why they have bought into the marketing pitch of having these difficulties eliminated by the host without them needing to encounter and solve them. I suggest that it is in fact the fiduciary duty of managed hosting companies to avoid causing these otherwise unnecessary problems caused by caching.
WordPress site owners should not have to play guessing games, usually through the hiring of 3rd party consultants, to figure out that their “managed” hosting partner was actually implementing caching tools that are not clear and obvious from the WordPress dashboard to a typical site owner.
The possible results of not changing?
To continue doing otherwise will have one of two results, neither one of which is good for our WordPress ecosystem:
- Business owners will find the burden of getting a hosted WordPress site to be too large compared to SaaS solutions, where customer satisfaction is paramount, and will leave WordPress with nothing nice to say about the experience.
- WordPress Software Creators and Consultants will continue to point the finger of blame towards “managed hosts” that create problems such as this, and tell their clients to move to hosts who don’t have such practices. Unfortunately, this is my current reality, where I have consulting clients who have wasted hours or days of time without realizing that their “managed” host was the source of all their troubles.
This problem is not new.
It’s been around since 2010 when one of the first and now largest managed hosting companies was founded.
But since then the nature of most WordPress sites has shifted from static blog sites to dynamic content sites with logged-in customers and members. These types of sites can no longer have caching imposed upon them by default.
And so it’s time for us to shine a light on these hosting companies and demand of them, for the good of all WordPress users and the professionals who have to solve this problem after the frustration has already been created, to please…stop caching your customers by default.