But remember that this series was motivated by an email from someone who thought that I could do a better job of explaining how transients and caching work in WordPress and why it’s important to understand how everything works in tandem with each other.
Understanding Caching in WordPress
So in this post, I’m aiming to bring it all together and talk about how the Transients API works in conjunction with MySQL, why it’s important to understand the relationship, and how to handle this moving forward.
How Do Transients Work in WordPress?
How Transients Work
First, according to the Codex, transients work like this:
This page contains the technical documentation of WordPress Transients API, which offers a simple and standardized way of storing cached data in the database temporarily by giving it a custom name and a time frame after which it will expire and be deleted.
And, if requested after expiration, is retrieved and moved back into its transient state.
So where lies the confusion?
As mentioned in the first post, I wasn’t clear about how long the transient information would be available. Rather than being a minimum amount of time the data will be available, it’s a maximum.
This means that if you set something to be available for a day, it will be available for a day. No less; no more. And after that time has expired, then it will have to be recreated into the transient state once again.
At least, this is the conventional wisdom behind it. It’s not wrong but there’s more to it. This is where it gets a bit more technical, though.
What Role Does MySQL Play?
As WordPress, hosting, and other technologies have matured, the underlying databases that power the application have changed, too. This isn’t a good thing or a bad thing (though perhaps we could argue it’s a good thing in a future post).
But it can help explain why transients work the way they do given the stack with which we’re used to working and how they may not work as expected with out database systems.
If you opt to use MySQL as the database for your WordPress installation, which I venture to say that most people still do, then the information that’s in the Options table (which is where transients are stored, too) then the Transients API will work as outlined above.
But what happens when you introduce other forms of caching like object caching through software like Memcached or Redis, and so on?
In that case, the data may not be available as you expect. In short, the caching software can choose to drop information that isn’t requested as often as other information. That is, it gives a level of priority to information that’s more frequently requested.
Moving Forward
When you take all of the above into account, you’re looking at several things:
the Transients API,
a database,
a third-party caching system.
When you have the Transients API and a standard database, you’re going to be fine in that things will work as you expect.
But if you introduce a third-party caching system, the outcome may be different. Specifically, things may not – and likely will not – work in the way you expect.
That is, the third-party caching system can disregard whatever information it wants to drop whenever it thinks it needs to remove it. This means that whatever you think you may have available in cache won’t be there.
Ultimately, the best advice I can give is this:
If you’re using MySQL and the Transients API, then things will work as described in Codex.
If, on the other hand, you’re using another caching system, then it’s important to understand how it works and how you can write code against it so it works as you’d like.
And with that, there’s nothing more to add on this primer for understanding caching in WordPress.
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:
user experience,
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.
Understanding Caching in WordPress
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:
During the first trip to a page, all of the information required to load the page is assembled.
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.
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.
Though the purpose of the article was to lay out a foundation for how we can design a class to work with the Transients API to simulate the behavior of cookies, one of the side effects of the article is that it didn’t do a good job of explaining how the Transients API (and, by proxy, how MySQL) works.
This was brought to my attention via email by David at UpDraft Plus.
So I thought it useful to talk about the concept of caching from a practical level, how it’s implemented in WordPress, then maybe look at we how to utilize plugins or newer technology to better power our sites and applications as well as have a better understanding.
Understanding Caching: The Basics
The concept of caching is relatively easy. But I think it’s best demonstrated by talking about data serialization and retrieval without caching, first.
Without Caching
Writing Data
Whenever you write information to the underlying database, you’re recording a record – or series of records – to the database.
For example, when you publish a post, you’re going to be writing a record to the table for posts and table for post metadata each of which are related by a post ID.
How they are related isn’t important for this post.
Instead, the thing to understand in this part is that when data is written to the database at least one record, if not multiple, is created.
Reading Data
When a visitor lands on the site to read that particular post, all of the information for said post will be request from the database, served to the WordPress application, and then rendered on the front-end.
Think of this entire process as a trip:
❓the visitor requests the page,
🔍 the web server identified what page to load,
📂 the page is requested from the database from multiple tables,
🏗 the data is assembled and sent to the core application,
🖥 the data is presented to the user.
So the trip starts when the user requests a page and ends when the information is presented to them in their browser.
It’s a Trip
And, without caching, this happens for every single user. That is, for each user that visits your site, a trip has to be made.
Understanding Caching in WordPress
That can get very expensive in terms of resource and time (especially depending on the size of your database).
But this is where caching can come into play.
Before Getting into Caching
The idea behind caching is to make this entire process faster. That is, if we know a trip is about to happen then we can keep the information in a place such that it’s already assembled and faster to retrieve.
Before talking about though, which I will in the next post, note that this is like making a trip to the hard disk of the server on which the site is hosted each time the site is visited.
Because, ultimately, the database, files, and all of the assets necessary to power the site reside on a hard disk. And yes, things like solid-state drives can make this process faster, it’s still not as optimal as possible.
And that’s where caching enters the picture. To better understand the Transients API, it’s important to understanding caching, which first requires a basic understanding how things work without caching.
It’s a Primer
So consider this a basic primer on how a database-backed site without caching works. And then we’ll build on this more in the next post.
Error: Running Homebrew as root is extremely dangerous and no longer supported.As Homebrew does not drop privileges on installation you would be giving all build scripts full access to your system.
