I hope you’ve recently noticed a significant improvement in the speed of the Division by Zer0.  I’ve done some further testing and I think I’ve discovered the perfect combination of tools which, at least for me, has made everything much snappier.

Last time I was playing around with Dreamhost’s FastCGI option ((Since disabled as it seemed to cause more problems than it solved)) as well as trying out a few newer caching plugins since Super Cache didn’t really play nice. Specifically I was testing Hyper Cache and DB Cache and trying to decide which one is better to keep. Well, in the end I figured out that using both is even better, and now I’m going to tell you why 🙂

Hyper Cache

This one is one serious mutha. It basically does the same thing as Super Cache but without requiring you to edit your .htaccess or other such hassle ((And removing it is simple too, unlike Super Cache)). All you have to do is activate and go. And the results are really stunning. With it activated, I routinely get pages loading in sub-second speeds (whereas before the average was 2-6 seconds) on cached pages with very low overhead, which means I can withstand traffic spikes.

I was so impressed I spent an afternoon just reloading pages to admire how fast they loaded 🙂

Of course this plugin will not help with javascripts speed so if you have a lot of ’em, you will still notice your site taking a bit. However you should notice that the loading starts immediately and then waits for each javascript to download and run (so you’ll see the page appear in stages) instead of waiting a bit until it even starts loading (while it’s gathering prerunning the php and quering the DB). As such, if you have most of your javascripts loading at the footer (as you should), your content will appear immediately for your audience to start reading, and by the time they’re one the second sentence, the page will have finished.

My main problem was exactly that incidentally, that the content took up to 5 seconds to even appear. As long as the main text is there, I don’t mind so much how long it takes for the rest of the “bling” to load.

Another good thing about hyper cache is that it will not activate if you’re logged in to your wordpress installation. This means that in order to see the speed of your site as it appears to everyone else, you either need to use another browser (I keep a konqueror lying around just for this) or to clear your cookies. On the upside, it means that you almost always see the current version when you make non-content changes, such as editing your theme (as the cache will be automatically cleared if you make content changes.) This really helps if you like to tweak your site layout a lot.

One last (bad) thing I’ve noticed is that if I go ahead and clear all hyper cache. My site will die with an internal server error. I’ve tried this twice now. I do not know if that is because my site would die if hyper cache was not there or because once the cache is cleared, there some heavy duty function running to repopulate it or whatever. I know it happens though. I don’t have to do this anymore however so it’s not really a problem.

Overall, Hyper Cache is an absolute win for people hosting their own WordPress, especially if you’re on a shared hosting plan and even more especially if you’re using Dreamhost PS, as Super Cache is not an option.

DB Cache

This plugin takes a novel approach to caching. Whereas all the other that exist simply save the html output of your content and then serve it to avoid running PHP code each time a page is requested, DB Cache saves database query output to avoid making SQL calls to it.

This has a few significant benefits. First of all, it helps with Search Engine crawlers such as the google bot. Where a normal caching plugin really shines when a lot of people access one specific page, it actually harms you when one agent accesses a lot of pages, since you add the cache-saving to your load, on top of the normal page loading. DB cache on the other hand, by caching common Database queries, can fill exactly that hole which significantly reduces the juice you need to serve all the bots crawling you.

This is becauseeach page of your site, other than the main content and possible some post-related queries (ie similar posts), has basically the same calls. 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.

So by caching all these common calls, you seriously reduce the time one needs to wait on a blank screen before a page can even start loading the content. You also reduce the load when a crawler does his daily thing and you even increase the speed of the occasional visitor from a mobile. While DB cache will not give you the awesome speed hyper cache will on a single page load, it will certainly reduce your overall server’s CPU & RAM load (much more important than bandwidth and disk space for shared hosting) and make visits to uncommon pages quicker.

Another plus which I’ve discovered is when you are using Gallery2 through the wpg2 plugin. Gallery is imho a database chewer because people don’t simply see one image and then leave, but rather switch quickly among a lot of them. As a result, DB Cache is perfectly prepared to grab those common queries done through wpg2 and save them for later, increasing the overall speed.

The caching combo of ultimate speed

Until now I’ve never mixed caching plugins as they all generally worked in the same or similar way. However the distinct way these two worked gave me the impression that they wouldn’t really conflict and might actually complement each other quite well. One of them is built for serving one page to lost of visitors in a short time period, while the other is perfect for serving many pages to one visitor. So I went ahead and activated both of them at the same time

And whatdayaknow, there was no explosion 🙂

What happens at the moment is that generally, a page always has at least a few queries cached by DB Cache. You can even see the cached queries increasing with each time it’s reloaded (when bypassing hyper cache). This in turn allows a non-hypercached page to load quicker which is then saved into hyper cache for further visitors.

So currently you see the results of this experiment. I’d like to believe that my speed at the moment is quite good and others who have followed my advice have experienced similar improvements. I really hope this is the last time I have to play with caches in the future and that the current speeds are not just an illusion.

Let me know of the results if you try the same combo on your own sites.