There’s a new WordPress cache plugin in town, and it’s called W3 Total Cache. This plugin is one of the contestants in the 2009 Weblog Tools Collection Plugin Competition.
The W3 Total Cache plugin (W3TC for short) is an advanced cache plugin, and you can only have one of those on your site at once. So if you’re currently using WP Super Cache, you’ll have to disable that first before enabling W3TC. [side note: I tried to find a good link for information about the advanced-cache functionality, but I came up empty. we need a Codex page for that]
If you’ve used WP Super Cache before, you’re probably wondering what’s different about W3 Total Cache? Everything. WP Super Cache is a static disk cache. It creates files on disk with a certain lifespan, and gets the web server to use those instead of firing off PHP to generate pages on-the-fly, thus saving CPU and time. So, on the bright side, it saves your server a lot of work. On the down side, you lose some of the dynamic nature of your site. The entire page will remain cached as-is until the cached version expires, or until it is forced to regenerate (because you update the page, a comment is added, etc).
W3 Total Cache works differently. It utilizes multiple techniques to improve performance, including: object and query caching; page caching; HTML, CSS, and javascript minification; gzip compression; CDN (Content Distribution Network) support; and browser caching via ETags. Currently, the caching is based on APC and/or memcache. I’ve suggested that they add XCache, as well.
Page caching is what WP Super Cache does. Except that W3TC uses your in-memory cache (APC or memcache). Memory being faster than disk, you’ll typically see an improvement when serving pages cached in this way. This does mean, however, that you want to have a decent amount of memory reserved for your cache. The W3TC docs suggest dedicating at least 128M with APC. If your server is strapped for RAM, or you can’t set up a dedicated memcache server, this plugin might not be for you.
Object and query caching means that the results of MySQL database queries are saved in the memory cache for later use. For example, when someone views your page normally, WordPress (or any other dynamic web application) will fetch things like your category list, your blogroll, and other information from the database, build the HTML page for the browser, and then promptly discard all of the database results when it finishes. The next time someone views the page, it runs all those same database queries again, even if nothing has changed, wasting CPU cycles and time. W3 Total Cache will save the results of these queries and other objects that WordPress builds in the memory cache for re-use.
Minification is the technique of stripping out unneeded information from your HTML, CSS, and javascript. This can include extra whitespace and comments. Depending on how your original files are formatted, this can result in fairly significant savings (probably 10-20% in many cases). The smaller the files, the faster they can be delivered to the browser. This technique also includes combining multiple CSS or javascript files into a single request. Normally, each CSS and javascript file linked to from your theme requires your browser to make a separate network connection to fetch it (a relatively slow operation). By combining these, the plugin reduces the number of network connections needed.
Gzip compression is a binary compression like you see with ZIP files. This is a more advanced method of converting a large file into a smaller one. Again, meaning you can serve it up to the browser faster. Delivering content to the browser as fast as possible is important, because the browser speed perception of the user can often determine whether or not they stick around to read that content.
Support for CDNs (Content Distribution Networks) means that you can host static files like images, CSS, and javascript on a seperate server. Typically, CDNs are optimized for static content. Some CDNs are also geographically distributed, and automatically route the requests to the nearest/fastest location. Even if you don’t use an external CDN (like Akamai, Amazon S3, or Voxel), you can set up your own server optimized for static content, and use that.
ETag support is currently supported in WordPress for feeds (I added that to the core myself, way-back-when). This is a feature of the HTTP specs designed to let servers and browsers coordinate caching. Basically, the first time a browser requests a page from a server, the server will generate an ‘ETag’ header with a unique identifier based on the last time the page was modified. The browser can save a local copy of the page in its cache, along with the ETag. The next time the browser requests the same page, it can send the ETag back to the server. If the ETag on the server-side hasn’t changed (the page hasn’t been modified), then the server returns a “304 Not Modified” response, which tells the browser to just display its cached copy of the page. W3 Total Cache extends this support to other WordPress-generated pages, not just feeds.
I’ve got the plugin running on this server currently. The only problem I’ve run into was that with the HTML minification “line break removal” option turned on, it caused my reinvigorate.net analytics script to fail for some reason. I haven’t fully explored all the options yet, and I don’t have as much memory allocated to memcached as I’d like, but it seems to be working pretty well so far. I should be able to judge more after it’s been running for a few days.
You can enable various optimizations independently of each other, so there is a lot of flexibility for utilizing various caching techniques while still allowing some things to remain dynamic. I’m curious to hear from others who try this plugin out, and see what they think about the balance between performance improvements and dynamic elements.
.