WordPress Caching Plugins and Observations with W3 Total Cache
Unless you have a large infrastructure behind you, if you want your WordPress blog to withstand a sudden surge of traffic then you need to be running a caching plugin.
There are many of these available and hundreds of different sites and opinions on the matter. As time permits, i’m currently in the middle of a bit of a side project to investigate the options and find a good, recommended setup.
As with anything, the best option for someone else might not be the best option for you in your setup, but here are some good posts which aim to compare and benchmark some of the popular options:
Apart from testing out WP Super Cache, the only plugin i’ve actively ran in production so far is W3 Total Cache. As I said in a previous post, the W3 Total Cache plugin for WordPress is a bit of a one-stop-shop performance plugin which includes features like Caching, Minifiying and CDN capability all in a single plugin.
Although the settings can be quite hardcore and a lack of documentation (it is after all free plugin of course!) means it’s not easy to understand unless you are familier with web page performance measures, W3TC is good and feature full plugin.
In my opinion though, it does have a few downfalls from a performance point of view:
1) It supports gzip, minification and future expires headers on css and js but it doesn’t support any kind of version numbering or cache busting technique. Because of this, you can’t set a far future expires header as if you need to change any assets then you will have to re-name them to avoid everyone’s browsers just pulling the old asset from the cache.
2) With the ‘auto’ minify mode, it actually uses php scripts to serve the minified css/js requests. I’ve not done any benchmarks on this but in my head i’m wondering if the overhead of serving them through PHP instead of static files would actually outway the gain of combining and minifying them? – it’ll certainly significantly eat in to any gain.
I’ve not tried the manual option yet, but looking at it, you can change it to manual, manually specify each css and js file and it will use real fies instead of using the php script to serve it and grey out the option to upload it to the CDN.
What I really want is for it for it to combine all the css & js files into a single .css and .js file and host it on the CDN with a version number so you can set far futures expiry and your web server is not dealing with serving them (plus you get the geographical, nearest location thing with a CDN). I’ll have to experiment with the manual minify option to see if that fulfills this.
3) Images used in the CSS are not served from the CDN. This means that even though you have al the CDN options turned on, there are still a lot of requests going through your server. The images are actually on the CDN but are not been used. I believe this happens if the url starts with a / which W3TC reads as a sign to serve it from the same domain as the CSS. I’m hoping that the manual mode above will help this.
It’s also worth nothing that if you use anything other than Disk Enhanced for the page caching module, it’s still dynamic. This means that despite using things like APC or Memcache to cache content in memory, which at a first glance you would think would be faster, it seems to often not benchmark as fast as Disk Enhanced mode or WP Super Cache. Both Disk Enhanced mode in W3TC and WP Super Cache write out static html files to disk which the web server can serve much faster than parsing and executing PHP. Disk Enhanced is therefore the quickest page caching option, at the expense of having to setup re-writes. APC or Memcache is easier to turn on and use, but doesn’t perform quite as well.
Please note, the version of W3 Total Cache I was using was: 0.9.1.4b (development version from Feb 2011) – the above are my opinions at the time of writing but I can not guarantee that things have not changed in newer versions.