Misconception: I don’t need caching
For a typical theme in wordpress, it needs to execute about 35 SQLs and 1000 of lines of PHP logic to yield a single page. Sure, modern servers are fast enough to do all this in split seconds. But when it comes to handling large traffics, like from Digg, Reddit,etc. it could easily prove out to be an overkill for the CPU. Put a Xeon or Core i7, just nothing would be able to handle 1000 simultaneous hits, without delays.
WP SuperCache
It’s among the bet known caching plugins out there. It caches post content, plugins and theme’s php executions firly well. Also, it let’s you compress the plain HTML in gzip for optimal bandwidth usage and faster load times. Gzip is so important that, just by enabling it, you can do wonders on saving your bandwidth. The difference is mostly of the order of 5x times or higher.
On the darker side, there are lots of pitfalls in wordpress, the most annoying one: sometimes it just won’t work. Recently, I changed my permalinks structure, and since then it started utilizing CPU higher than ever and also reduced page load times. It increased from 1 second to 10seconds – horrible.
Tried debugging several aspects, read several guides on fixing it, but nothing helped. It was time to look for alternatives.
Hyper Cache
Hyper Cache, basically, uses similar concept and does all that without touching your .htaccess.This could be good for people who have long .htaccess with large no. of mod_rewrite, other operations.
The performance was similar. With SuperCache and Hyper Cache (with gzip enabled on both) loading times were 0.6s and 0.77 seconds, respectively.
There are pitfalls too. Unlike SuperCache, which let’s you choose whether to serve cached or DB based pages to logged-in users, hyper cache defaults it to fetch from DB. On the upside, if you keep on modifying theme, like me, it always serves you the latest page without the need of clearing the cache.
On the good sides of things, It has one additional feature: Realtime Statistics. It shows you the kind of benefit you avail on installing Hyper Cache. It draws simple graphs to represent count of how many hits did you receive and out of them how many were actually served via Cache vs. Database. It also covers the clients that didn’t support gzip compression and plain html was served for them.
Overall, Hyper Cache is great for people hosting their own WordPress, especially if you get a lot of traffic or you are on a shared hosting plan.
DB Cache Reloaded
This plugin is modified version of it’s parent: DB Cache. DB cache had some inherent bugs with tags that never got resolved. DB Cache takes a different approach to caching. DB Cache caches database queries For instance page x took 35 queries, it caches them all for the next page atleast 15 would be similar (which belong to header, sidebar, footer, plugins). Your recent posts, your tag clouds and category lists, recent comments etc, depending on what widgets and theme you use. These generally don’t change from page to page but for a normal caching plugin on a new page, they still need to be called so that the full html page can be saved. This way you can reduce no.of hits to the database and improve speed. DB Cache reloaded makes it even better with bug fixes.
On one side it helps w.r.t Search Engines. A normal caching plugin outperforms when a lot of visitors access one specific page. On the other side, it actually harms when one crawler accesses a lot of pages, most of them being outdated. DB cache reloaded, by caching common Database queries, can fill exactly that hole which significantly reducing the CPU overhead used to serve all the bots crawling all the pages.
You also significantly reduce the load when a bot does his daily mass crawl. While DB cache will not give you the speed hyper cache will on a single page load, it will certainly reduce server’s resources utilization.
The Deadly Combo
First, when I thought of combining the two, it sounded crazy. I thought it might conflict the other. But, the distinct way these two worked, encouraged me to give it a try on my local setup. In actual, they wouldn’t really conflict and can actually complement the pitfalls quite well: One is designed for max performance for users and other one worries about Google bots.
Why both still work, together.
Practically, when you run them collectively, DB Cache Reloaded takes precedence, the first time page is loaded. On subsequent page loads, it always has at least few queries cached by DB Cache Reloaded. Proof is, the cached queries increase with each time new page is reloaded. This, as a result, allows a new non-hypercached page to load quicker, since we already have few cached queries fro the new page, which is then saved into hyper cache for further visitors, Making it non-conflicting combo.
I saw the improvement in Cache Misses pages on Statistics. The missed pages were alot faster than before. (order of 4x times)
Overall, This combo has given the fastest load times ever. It enabled me achieve best of the both worlds, without comprimisng on any aspect, beyond what WP SuperCache has to offer.
Try the combo, and let me know what you think.