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. The closest other plugin is probably Batcache, which also uses a memcached backend for caching.

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.

I’ve pulled the trigger on the first stage of my site re-theme.

Right now, it’s still a pretty clean slate. I’ve switched over to the Thematic theme (actually a child theme using Thematic as its template), and done just a few quick stylesheet fixes and personal plugin tweaks. Currently, there are still a few warts which I need to iron out (some sidebar styles on sub-pages that need fixing, and such).

More major style/branding changes will come later, but this “tabula rasa” state of things will help motivate me to continue making changes.

If you spot any obvious glitches, please feel free to point them out.

In a few weeks, I will be a presenter at WordCamp Birmingham 2009 (that’s Birmingham, Alabama, not England, by the way). Last year, I did a presentation on “The Future of WordPress“, shortly before the release of version 2.7. I briefly considered doing the same thing this year, updated with speculation about the upcoming versions 2.9 and 3.0, but that seemed like a cop-out. I wanted to do something a little deeper.

One of the things that always frustrates me about starting to work with a new programming language, or with a new framework for a language I already know, is the initial learning curve. Everybody wants to start out with the ubiquitous “Hello, World” example, which is great for a quick syntax example, but is pretty useless for practical purposes. I always want a good primer which doesn’t assume I’m a complete beginner, and dives right into useful examples. I want to know how to find the existing pieces of the system that are going to make my life easier. So I thought others might appreciate something like that for WordPress plugin programming.

So that’s going to be my presentation topic this year. I’m going to try to create an introduction to creating plugins for WordPress. While there are bits of the process that can be complex, the real meat of the API hooks (filters and actions) are really pretty simple. And I think that with a good overview, those who aren’t already familiar with programming for WordPress can get up-to-speed more quickly than if they had to discover everything by searching the web and using trial-and-error. While I will try to keep things as simple as possible, I’m going to assume that my target audience will at least have a basic knowledge of programming concepts to include what functions and arrays are. You won’t have to be a PHP expert, or even be able to sit down and write a program from scratch without a reference book handy.

I will, of course, make the presentation available online when the WordCamp arrives. And since I’ll be limited by time in my presentation, I’d like to publish an expanded version here later as a series of articles where I can go into more depth.

I’ve already started a rough outline of what I want to cover. But I’d welcome any ideas or questions on this topic. If you are already familiar with programming, but you’re new to programming in the WordPress framework, what questions have you had? What concepts confuse you? What areas would you like to see covered?