I’ve mentioned my Cache-Control plugin for WordPress before in passing, but I’d now like to explain what it does in more detail.
The Cache-Control plugin for WordPress does what the name suggests: gives you greater control over the HTTP Cache-Control header in WordPress. The Cache-Control header is used to instruct client and intermediary caches whether they can cache a resource and for how long. By default, WordPress won’t present any caching preferences except for in a few circumstances such as a 404 Not Found responses where they’re explicitly declared as uncachable.
With the Cache-Control plugin, you can specify how long client and intermediary caches should store different types of pages generated by WordPress. For example, pages can normally be cached longer than the front page and search result pages. Likewise, dated archives for time periods other than the current date can normally be cached for a long time as these aren’t likely to change often.
You can even specify different times for clients (max_age) and intermediary (s_maxage) caches separately. As an advanced feature, you can set a pagination factor – allowing for things like caching page 66 of your most popular category to be stored 66 times longer in cache than page 1 and 2.
Cache-Control generates a standards compliment caching header that takes the needs of the site owner into account. Pages generated for logged in users will be indicated as uncachable which should help prevent caching mishaps.
Download Cache-Control plugin from the WordPress Plugin Gallery to take control of your website’s cache. I’ve written up extensive documentation on how the plugin works and how you should configure it.
One of the biggest worries I’d when it comes to deploying caching in front of a WordPress blog was losing the ability to simultaneously update the front page, taxonomy pages, and feeds when I published a new post. Cache-Control for WordPress is the only plugin for setting and managing caching headers that will dynamically reduce cache times when a scheduled post is imminent.
This means you can set long duration caching headers for most page types, including the front page and feeds, to take full advantage of caching, and have every page be up to date when a new blog post is published. There’s no extra configuration or anything to think about. As long as a post is scheduled, the caching duration will be reduced to a few seconds after the blog post is scheduled to be published.
This doesn’t solve the problem of keeping things up to date if you publish posts immediately. The plugin can’t predict the future, but it will adjust accordingly if the near future is made known to it in advance through the WordPress publishing schedule. A small random factor of 30 seconds is introduced in an attempt to spread out the cache revalidation requests when using this feature.
404 Not Found pages are one of the few types of pages where WordPress sets a Cache-Control header by default. Unfortunately, you’ll most likely want to cache even these pages for a short while if you’re aiming to keep the load down on your web server. Generating a new 404 page for every misguided visitor is both inefficient and unnecessary.
Performance-wise, the plugin requires three–four database queries per page. These should be cached by your database solution and not add any extra load. One of the main advantages of using this plugin is that you can deploy caching in front of your web server and thus significantly reduce the load on your web and database servers by reducing the total unique requests that aren’t served by the cache.
The plugin’s settings page is admittedly a nightmare, but the defaults should be good enough for anyone who doesn’t know that they need to tweak them to be different than the defaults. At least, that was the intention.
New in version 2.2: You can now set the stale-if-error and stale-while-revalidate header fields as per RFC 5861. Improved documentation.
New in version 2.0: Will now [optionally] double the max-time for old and stale blog posts. The max-time is multiplied by the number of years since a post was last modified or commented on. Cache-Control will now also allow caching of HTTP 301 Moved Permanently redirects that are generated by WordPress. (Permanent redirects are intended to be permanent, after all.)
Download Cache-Control plugin from the WordPress Plugin Gallery, read the documentation, or grab the source code from WordPress Plugin Hosting (Subversion).
I’ll write a longer piece on caching with WordPress that I expect to publish in about one-months time. Make sure you sign up for the newsletter so that you don’t miss it!
WordPress is a trademark of WordPress Foundation. The Cache-Control code is free software licensed under the GPLv3.