In an attempt to try to address some of the common issues that we’ve seen others encounter when managing their WordPress-based blog, we’ve been taking a look at the reasons behind the problems and providing a bit more information about what to expect in a given situation.

We’ve covered theme compatibility & plugins and third-party commenting systems. The last major area that we’ve noticed represents a considerable pain point for bloggers is caching.

Let’s take a look.

“It won’t update!”

It’s not at all uncommon to install a caching plug-in, activate it, and let it do it’s thing. For the most part, it’s easy to forget that it’s even working.

That is, until you make a change to, say, your CSS, or the content of one of your pages. You know caching is working in those moments because your site updates are no longer immediately visible, but instead take 15 minutes to be reflected on your site.

So what’s going on?

So Sorry, No Cache Here

In order to understand how caching works, we must compare two different scenarios on a step by step basis. The first will be a basic WordPress setup without caching. This is how WordPress works right out of the box. The second will be a typical setup for a WordPress blog running a caching plugin of some sort.

WordPress Blog – No Caching

Here’s what happens when someone follows a link to one of your blog posts.

1. The request comes into your web server (host) and it gets passed to WordPress.
2. The WordPress application takes a look at the incoming page name and uses that information to go deep diving into the WordPress database to hunt down everything related to the blog post on the requested page. It finds the post content, the title, the author, not to mention all the comments, you get the idea.
3. The WordPress application uses this data, in conjunction with the theme’s template and CSS files, to build the single page (blog post) that was originally requested. It sort of puts everything together like a jigsaw puzzle right there on-the-fly.
4. The newly assembled page is sent to the requesting browser and then forgotten about. The puzzle pieces are disconnected and tossed back into the box again.

This cycle happens on every single page load. Using our puzzle analogy, all the pieces are fetched from the box (database), the entire puzzle is assembled every time a visitor hits a page on your website, and then the puzzle is broken down again. You may have caught onto this already, but it’s important to note that within the economy of WordPress’ internal workings, fetching data from the database, and building web pages with it, is time consuming and expensive.

Cache is King

Caching is an attempt to mitigate this frequent reading of the database. Here is how the workflow would run with caching turned on.

WordPress Blog – With Caching

Actually steps 1 – 3 happen like before. But things take a turn at step 4.

4. The newly assembled page is sent to the requesting browser and then a copy is made in memory. A copy of the puzzle is saved.

Instead of the newly assembled blog post being trashed, a copy of it is saved in memory. Then, all subsequent visitors who ask for that page get the in-memory copy! Our jigsaw puzzle has been assembled and preserved. The next person that wants to look at it doesn’t have to put it together first.

Reading from memory is fast, especially when compared to the database alternative, so the site sees a performance increase. Bottom line, things run faster.

The thing is, this behavior comes at a cost – namely, that if you make updates to your theme or content, your users may not see those updates immediately. They’ll be seeing the older cached “copies” of your pages.

So why bother?

On one hand, it totally looks like caching can detract from the experience of your site. After all, you’re trading performance for what users may see whenever they hit your site.

On the other hand, caching is a major step in taking precautions so that your blog doesn’t buckle under a massive amount of traffic. And that, perhaps, is the biggest win.

Like we mentioned before, WordPress will request information on the database with every single page request. If you receive thousands of hits in a relatively small unit of time, the application can buckle. This isn’t necessarily related to WordPress, either. Server host configurations can temporarily shut down your account based on high traffic, too.

Caching helps prevent that. Because the application is pulling information from memory and not the hard drive, there’s less work for the application and server.

The two biggest takeaways from this particular post will hopefully be a better understanding of caching and a clearer idea on whether or not your should be using a caching plug-in on your site.

Hopefully this series has helped to cover to some of the more volatile areas of managing WordPress-based sites. If not, what did we miss?

[images: intvgene, zigar]