Caching – “Because It’s Faster, Of Course”

Previously I wrote about Effective caching with WordPress and how I ended up improving the site speed by nearly 400%. I wanted to talk more about how you should never blindly trust that a caching solution will help make your site faster.

The basic concept of caching is to save the server time by keeping expensive processing to a minimum and making that information readily available.

If you look at some of the changes made in the previous article a big one was server configuration. Not all web hosts are cutting edge. In this case, the hosting company supplied the server with PHH 5.6. Making the switch to 7.0 reduced the PHP execution time by half. But I was left with a lot of overhead when WordPress made external calls. In truth, there is a lot of performance to be gained by disabling WordPress CRON and even disabling Jetpack.

But those improvements aside. I want to talk specifically about why not all caching solutions work out of the box. Especially for custom development and themes.

Hunting down the culprit

In this example a custom rewrite rule was used to retrieve data from a remote source. First by creating an elastic search query, sending it to the API and consuming that via the internal WordPress API. Lcache had little to no effect on performance. This was due to the fact that the plugin developers had not considered performance and a caching strategy was not part of the initial plugin development.

Adding to the problem the site used the templating engine called Timber which does have support for caching but by default uses Transients which is a temprary data store using the sites Database.

Properly planning for serverside caching

As I mentioned, Timber does support caching and luckily can easily fixed by correctly configuring Timber.

Back to the offending custom plugin. After assessing the functionality I decided to make a few changes to the plugins main “get” method converting some query parameters into cache keys and setting wp_cache_add in conjunction with the WordPress Lcache plguin I had dropped the overall web external time by nearly 300ms.

Conclusion

Caching is never, unfortunately, a silver bullet, you can’t just turn it on and reap the benefits. This, however, is not true for all caching and or scenarios. But in this situation, the host supported APCu and had Redis in place. The site was also far to big at hundreds of Multi sites and millions of page view a month. It had dynamic personalized content to bother with any WP Super cache or comparable plugins.

I hope this has left you with a better understanding of how you should consider an approach more complicated and advanced development with WordPress. Knowing how, what, and when to cache something even if you don’t need it at that moment can save you a lot of frustrations down the road.