The Cache-Control plugin for WordPress does what the name suggest: 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 uncacheable.
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 the 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 over your website’s caching.
One of the biggest worries I had when it comes to deploying caching in front of a WordPress blog was loosing 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 is 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 doen’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 webserver. 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 really add any extra load. One of the main advantages with using this plugin is that you can deploy caching in front of your web server and thus significantly reduce 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.
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.