Understanding Caching in WordPress, Part 2

In the previous post, I shared a basic primer for how database-backed applications – specifically WordPress – work without caching.

And before we talk about how basic caching works in WordPress, namely with the Transients API, it’s important to discuss the basic principles of caching. This includes why we do it, its benefits, and how it works.

Then we’ll get into how we can take advantage of basic facilities in WordPress to actually do this.

Understanding Caching in WordPress: Caching?

Why We Do It

Generally speaking, we do this to make sure our sites are fast. We know that speed plays a role how a page is ranked in search results. And though that may not be the primary reason, it’s an important reason.

Perhaps the simplest and best argument for caching is to have a fast site (or a performant site). And, in this context, this may mean a site or a web application.

Regardless, we know what it feels like when we’re sitting there waiting for a page or part of a page to load. If we don’t like it, why would we want our visitors to experience that?

Its Benefits

The benefits of caching come in at least two main areas:

1. user experience,
2. time to load.

In the last section, I said the benefits of caching can be felt if you’re a user. It’s something we’ve all experienced and, as developers, it’s something we can offer to our users through a variety of techniques.

But “time to load” is also something that matters and this is not just talking about the benefits of how long it takes for a user to load the site. Instead, it’s a bit more technical.

Recall in the previous post that a request – or a trip – starts from when the users requests information from the server and then the process goes from the user’s machine to the server to the database and back again.

When we’ve introduced caching, we don’t have to do all of that. Instead, a trip is shortened because the data is actually kept somewhere else. And if the trip is shorter (and I don’t mean from the user’s computer to where the server is located in the world), then it should also be faster.

But how?

How It Works

There are numerous types of caching that are available but I’m keeping this particular series high-level. That is, I’m not going to distinguish between a browser cache, page cache, object cache, etc.

Perhaps in a future post. But, for now, I’m talking specifically about caching at a high-level.

Anyway, here’s how it works:

1. During the first trip to a page, all of the information required to load the page is assembled.
2. Rather than discarding it when the user leaves the site (or the page), the information is kept somewhere that’s easily accessible like the server’s memory.
3. When the next user hits the page, the trip doesn’t have to go to the database to get all of the information, assemble it, and then return it to the user. Instead, it pulls the fully assembled information from the server’s memory (which is, in most cases) already faster, and then returns it to the user.

There are plenty of caveats to consider when doing this such as customized user data, partial page loads, and so on, but the principle behind the trip remains the same.

WordPress Transients

So how does this work in WordPress? At the most fundamental level, the Transients API provides some basic functionality for this.

But it’s important to understand how it works and why it works the way it does. So in the next post in this series, I’m going to talk specifically about that.