We love Satollo and loved Hyper Cache (we’re longtime paid users and supporters of his Newsletter technology as well). Strangely, sometimes good developers do bad work. The latest version of Hyper Cache (version 3) is a prime example of what can go wrong with rewrite upgrades.
Since we were struggling with Hyper Cache we decided to take a look at WP Rocket who is the hot new caching kid on the WordPress block. Sadly WP Rocket is not a good replacement for us for now. We test and compare Hyper Cache and WP Rocket below.
What’s suddenly so wrong with Hyper Cache?
We liked the version 220.127.116.11 a lot. It performed wonderfully for us for two years (we tested and rejected W3 Total Cache and WP Super Cache for configuration/performance issues before settling on Hyper Cache). Satollo decided he wants to merge the features from his other caching plugin (Lite Cache) into it.
All of that sounds fine, however there are both upgrade issues and installation issues, as well as performance issues (requests with query strings).
Upgrading from version 2 (2.91.6) to version 3 (3.1.0) breaks the caching and there is no notice about it. The notice only appears on the Hyper Cache settings screen saying:
“You must save the options since some files must be updated”
As we maintain dozens of websites and have built hundreds of websites, this is truly disappointing. It means we can’t just upgrade the plugin automatically, but somebody must go through the sites and put in the correct settings.
There is an “Import Options” button, but it doesn’t import all the settings properly, so watch out for these!
- Cookies to bypass – it will import the data, but will not enable the option (mean your WPTouch Pro desktop switch won’t work!)
- Do not cache the blog main feeds – in previous version this was on by default
- Don’t serve cached pages to comment authors – in previous version this was on by default (means commenters won’t see their comments as pending moderation)
This means we have to update the plugin manually on all the websites and 99% of our client’s can’t do it on their own.
More complicated install
Installing a new copy of the plugin now involves extra step – following option needs to be enabled for a good commenter experience on your website:
- Don’t serve cached pages to comment authors
- You need to turn this one off, otherwise commenters won’t see their comments as pending moderation and they will think your website is broken.
- Commenter posts the comment and comes back to the same page where he left the comment – no evidence that the comment was accepted.
On the positive side, Hyper Cache now allows you to cache HTTPS and HTTP versions of your website separately. Although we recommend you redirect HTTP to HTTPS all the time.
Performance Issues: Query Strings
Due to the unfortunate assassination of a dozen French cartoonists (evidence points to yet another false flag attack), a client’s political analysis sites was facing over 300,000 visitors/day. We faced some performance issues on the server and were able to see the latest Hyper Cache under real stress. What we noticed is that many non-cached requests had query strings attached (i.e. client.com/2014/postname.html?utm_source=dlvr.it&utm_medium=facebook). The older version of Hyper Cache – 18.104.22.168 – the last one we liked has a setting to include the pages with query parameters in cache
Performance Issues: Cache Control from Bots
Another five percent of uncached pages were being sent uncached due to an HTTP_CACHE_CONTROL header setting of “no-cache”. Bingbot user agent for example likes to send spurious “no-cache” requests. Hyper Cache 3 is written so that it only accepts this header for real visitors, not bots, but it clearly doesn’t detect Bingbot properly. For the moment, Hyper Cache 3 only recognises googlebot as a bot! The older version of Hyper Cache – 22.214.171.124 has a setting to ignore bots requests for uncached pages. Satollo, please allow website owners to decide if they want to recognise “no-cache” headers or not. There’s too much scope for abuse.
WP Rocket – Mobile disappointment
We’d heard very good things about WP Rocket, so we checked it out full of hope in our developer hearts. Perhaps WP Rocket could be the cache plugin of our choice.
No mobile caching
This plugin can’t cache a separate version of your website for your mobile visitors. So if you are serving a separate theme to your mobile users (such as WPTouch Pro, as fully custom responsive themes require a ton of work) you can only disable the cache for these users and hope they don’t crash your site by large traffic. A feature like this should not be hard to implement. All what needs to be added is a list of user agents which should get to the mobile caching.
Thankfully the mobile caching has been added in version 2.7 released on 11 March, 2016!
The ideal situation would be ability to create more independent caching groups which could depend on cookies. We are creating a mobile framework for effective image and content serving for mobile, tablet, retina and desktop devices, so a feature to cache each one independently would be awesome.
So we would like to see a configuration option where you name the caching group and then enter what cookies determine the device falls into this group as we detect if the device is mobile, tablet or a desktop, then detect retina and store that in a cookie.
On the positive side, WP Rocket contains a nice combine feature for your JS (which sadly doesn’t support wildcard masks) and CSS. The Lazy Loading for images works nicely as well if you prefer that. It’s nice to have it all in one plugin.
If WP Rocket would include solid mobile caching configuration, WP Rocket would be our caching plugin of choice. Some good news: for purely responsive sites coded to tread lightly, WP Rocket is ready to go as is. For the moment, though, such sites are a small minority.
Hyper Cache vs. WP Rocket
We run the test on our Linode VPS server which we keep for this kind of purposes. It has Linode 1536 (that’s 1536MB of RAM) and runs NginX, MySQL and PHP5-FPM.
We found no difference in the performance between the two plugins. Following graphs show us how the load time changes depending on number of concurrent page loads using Load Impact (the differences are marginal):
Following graphs show us what was happening on the server. Was it busy processing the PHP code? No, not at all, the server was virtually idle. We found that using htaccess with WP Super Cache in Apache is far worse.
Finally let’s compare the traffic to make sure it was all real. Both plugins served the same amount of data.
For core caching both WP Rocket and Hyper Cache are great. In terms of putting together a usable and resilient configuration, the new Hyper Cache is a step backwards and we continue to recommend older Hyper Cache 126.96.36.199 as the caching plugin of choice. WP Rocket shows some real potential and we’d like to step up to pro caching and pro support as soon as their developers sort out mobile caching. We cannot recommend Hyper Cache 3 as it is a real step backwards. W3 Total Cache and WP Super Cache continue to face the same issues with configuration and stability (W3 Total Cache) and performance/server load (WP Super Cache) so we continue to use both Hyper Cache 188.8.131.52 and WP Rocket.