WordPress host SiteGround recently announced a new feature, SuperCacher and up to 5 times faster sites for all!: “Today we take a major step that will result in a much more massive adoption of the other two SuperCacher layers and will significantly increase the speed of the sites we host. We now make Dynamic Cache and Memcached available at no additional cost on our StartUp plans too.”
This is sweet and simple, load WordPress sites in as fast as 37ms with Cloudways!
Sounds great right? Well I omitted the last sentence of the original paragraph in the quote above, “Additionally, the dynamic cache will be activated on our servers by default.” Ooops. In the comments area there are a number of complaints and issues regarding just blindly turning on the switch for all users – similar to auto updating. Some of the comments:
“We specifically turn off cahce’ing in out sites because we have created custom code that uses server side sessions for managing logins and other behavior.”
“I have issue since you have enabled Dynamic Cache on my accounts. 7 websites on 7 different siteground accounts”
“This broke my WooCommerce store last night with hundreds of users trying to buy. It was mixing the carts and checkout details from guest users.”
And the obvious statement:
“First of all, you should have let your customer know about the change before it happened, while I received the email only after the new Super Cacher was made available. Not everybody is using WordPress or managing the cache through plug-ins. Just like Mark Stein pointed out, some of our users saw cached pages from other people’s sessions. Yes, it is legacy custom code, but we should be free to decide how to manage dynamic cache or – at least – we would like to have the time to make changes in our code in order to deal with your caching.”
So it really boggles the mind why something like this would be rolled out with what appears to be zero notice, and depending on the type of site, a relatively awkward fix that involves editing .htaccess.
I’ve known the SiteGround team for many years and am surprised by this kind of infrastructure push. The answer from Hristo Pandjarov in the comments on why there is no easy switch probably irks me, “Defaults are important and we want to make sure that all the performance optimizations are being used. Caches are what make the modern websites fast and performance becomes more and more important. Having a simplle way of deactivating them is not ideal.”
Defaults ARE important. Overall performance IS important. Not building a simple way to deactivate is NOT customer friendly. Bury it in advanced features. Users, no matter how technical, are more and more accustomed to simple controls even for advanced features. This is the way of the internet, and those who can provide ease of use will succeed over those that can’t.