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.
- The request comes into your web server (host) and it gets passed to WordPress.
- 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.
- 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.
- 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?
Ben Miller says
Which caching plugin do you recommend?
Tom says
WP Cache and W3 Total Cache are the ones that I’ve trusted.
Cliff says
Great article! The bigger a site gets function-wise, the more it needs caching. The trouble comes when database caching starts conflicting with plugins and you don’t realize it. It’s worth the trouble, but it’s certainly not a simple one-step problem-solver in most cases.
Tom says
Definitely.
Building an entire site off of a mish-mash of themes, plug-ins, and add-ons can be a recipe for all sorts of problems unless stuff is either carefully evaluated before activation or just developed in-house.
Matthew Snider says
A great write up yet again. Caching is such an important thing for any page. If you install firebug and some of the tools it runs, you will get hooked as I am on the small numbers around page size and loading times.
Caching is key, tools such a W3 Total Cache can be all the difference in seconds that matter. Utilizing such tools along with a S3 from Amazon to host all of your images and scripts can make a HUGE difference. A CDN is a great thing also.
To stay on topic, you HAVE to cache your pages along with your DB as to limit as many hiccups server side as possible.
Hit me up if you have any questions, I use W3 Total Cache on all of my sites and love it.
BTW if you want to see changes you just made do a control F5 in windoze or Command, Shift r on a Mac to see it immediately.
Tom says
Yes, you’re right – not caching the database is kind of defeating the purpose.
..and over time, doing the hard browser refresh becomes near habitual if you do it enough 😉
Jason says
I’ve played around some with W3 Total Cache, but it can get pretty confusing pretty fast (for me at least). One problem I ran into is that RSS feeds that were displayed in a sidebar wouldn’t update, or they would update at different intervals depending on which page you were on.
Do you know if there’s a way to exclude certain parts of the page from being cached? For example, excluding sidebar.php while caching everything else (header, footer, etc.)?
Matthew Snider says
Seems like this should fix your problem
http://wordpress.org/support/topic/plugin-w3-total-cache-rss-feed-caching-not-working
Yohan Perera says
My hosting provider doesn’t allow wp-cron.php in their servers. Therefore no caching is possible…!
Matthew Snider says
Honestly, it’s time to move on if they can’t support a native WordPress function. Lot’s of backup plugins require this also.
Tom says
Ew. Lame!