Once you start turning your WP site into something more than a basic blog, you’ll be adding lots of functionality that will start weighing heavier and heavier on your database. With every new feature you put together, your database query count is only going higher and higher.

I find that even putting together a page with no more than a couple of widgets and a slider can get your query count into the hundreds.

Just setting up a fresh theme off CodeCanyon can turn your query monitor red. That’s painfully true even for some of the popular ones that try to do everything under the sun, yet fail when it comes to performance.

There are plenty of ways to deal with these, but today I’ll talk about transients.

What are transients?

WordPress introduced a few years ago a new way to temporarily store various structured data in the database and have it easily accessible in just one query.

The data is usually some processed piece of information that you use more than once. It doesn’t (often) change from one use to the next, so it’s not necessary to reprocess it every time. And it automatically expires after a while.

It’s basically a simple way to cache some frequently used data.

When should you consider implementing transients in your code?

You often build something that is excessively heavy on the database. You add a query in here, another in there, another inside a loop and just like that, you now have hundreds of database queries on every page load.

Case in point:

We had a client that needed to have a page which listed ALL product categories and ALL products associated with each one. Not only that, but for each product we needed to include an image, the tags, the labels (a distinct term), the WooCommerce rating, various custom fields, titles, descriptions, etc. And each of these could be from multiple sources (the image could be either a custom field or the featured image, the description could be custom or the excerpt. And others.

You get the picture. A mess.

With 25+ categories and about 5-10 products for each, you can imagine how this quickly spiraled out of control to about 600 queries per page load.

Granted, the server is quite solid, and this wasn’t increasing the load time too much. But still, numbers like that should give you the creeps.

A lot can be said about optimizing those queries. And it should be done. It is the right way to do it. Given more time, I would go and do that first.

In this case, however, going for the low hanging fruit of using transients was the quick and dirty way of handling it and it gave us the biggest bang for the buck.

You see, about 450 of those queries were associates with putting together the data needed to render the product cards. At the end of all the database interaction we had one final structured array which we would then loop through to render the categories and products.

Given that the data doesn’t change from one user to another, we decided to store it into a 12 hour transient and use it from there.

Everyone visiting that page over the next 12 hours would get the cached version. Instead of doing the 450 database queries, they would only do one!

At the end of those 12 hours, the transient would be cleared and one unlucky soul would once again load the page with the full 450 queries, but he would hardly notice, as that still take less than a second.

It’s a good bargain in order to deliver a fast experience to the vast majority of your visitors.

When not to use transients?

I can think of three situations where transients could seem the way to go but might actually cause trouble:

• When you only need to load unprocessed data. Just doing the query might be faster.
• When you need data that is stored in WP options. Just make the options autoload and WP will load them all in one go.
• Any time when saving several queries might complicate your code. It’s not worth losing readability just to reduce the query count by 2 or 3.

Conclusion

Take a look at your code with a good benchmarking tool like Query Monitor.

Does anything stand out? Is it red?

Do you see any duplicate or very similar queries? There’s an opportunity there to refactor your code and do more with less.

Stay tuned. I’ll be back with another post with several easy examples you can implement.