Designing Cachable WordPress Sites

With the advent of social networking—especially sites like Digg—making sure your WordPress website is cachable can mean the difference between a surge of new visitors, or a database server crashed.

In this case, “cachable” refers to server-side caching; allowing a caching mechanism (either the built-in caching system or WP-Cache) to serve cached files instead generating fresh copies upon every visit.

The caching process is this: a visitor a page on your website. This users browser asks your website for the latest version of this page. Your WordPress looks to see if a cached version of that page is available. If it is, it serves that, otherwise creates a cache file and then serves it. When it works well, it’ll not only speed up your site, but save your ISP quite the amount of CPU cycles on the database server. If your site has ever displayed WordPress database error messages or your site just generally feels slow, you can almost certainly benefit from this.

There are, however, a few things to keep in mind when designing a cachable WordPress website:

  • Consider the cache expiry time. A long expiry might be needed in extreme cases, whereas a short expiry time will increase the usefulness of certain dynamic fields.
  • If you have access to statistics on your webserver, see which of your pages get the most hits, and have those pages designed to be easily cachable.
  • Usually, caching your blog homepage and your feed will be enough for most.
    In extreme cases:

  • Minimize the use of dynamic content on your pages, so no cached information will be obsolete.
  • Consider not showing number of comments on your main blog homepage—these will likely turn inaccurate rather quickly.
  • Consider using a static date format for your post dates. A static date would be 25/11/1979, whereas a dynamic date would be 27 years, 3 months ago.
  • Place comments on separate pages.

3 thoughts on “Designing Cachable WordPress Sites”

  1. Orderer says:

    Simple, useful tips – many thanks.

    But, it would be nice if you fleshed out the teasers, giving examples using numbers, ranges etc. What is “long” and “short” with regards to expiry time?

    Also, just a small inaccuracy – how could “27 years 3 months ago” be dynamic, really – it will only change once every month 🙂

  2. Joen says:

    But, it would be nice if you fleshed out the teasers, giving examples using numbers, ranges etc. What is ?long? and ?short? with regards to expiry time?

    Right now, I’m using an 1800 second expiry for cached pages on this site. That’s half an hour. That works well for me, with the level of dynamics I’m using.

    3600 seconds is, of course, an hour, which I suppose is the upper end for the “short range”. Anything above that I’d consider a long expiry time.

    In cases where there is little or no dynamic elements (such as brians latest comments), you might as well set your timeout to ten hours or more.

    Also, just a small inaccuracy – how could ?27 years 3 months ago? be dynamic, really – it will only change once every month 🙂

    Yeah I suppose that was a bad example 🙂 Coincidentally, it’s my age.

  3. Orderer says:

    Hmm, just thought about it now – if the site’s not being visited too often, then why bother caching at all? A cache of an hour sounds really, really long 🙂

    Often times, it is not the main page that bears the brunt of a digg as much as a particular blog post or site page. Extending the principles you propose to all the pages would be real difficult. I agree that on the whole, it is better to cache than not – the load on the CPU will be lower, for one.

Comments are closed.