WordPress Transients: Back to basics for performance optimisation

It can be easy to overlook or be unaware of basic site optimisation techniques. However, any site optimisation strategy should look at every available option.

Most WordPress developers will be aware of the ‘wp_options’ table, for storage of plugin data for example. WordPress also has built-in functions that cater for the storage of time-limited or ‘transient’ data.

WordPress Transients are a great way to store the results of resource heavy queries or processes. WordPress’ database structure can often lead to inefficient database queries, especially at scale where the blog holds many thousands of posts.

The storage of the results of these inefficient queries into a WordPress Transient can massively reduce the processing load required to render a page.

WordPress Transients: Back to basics for performance optimisation

Even if a relatively short expiry period is used, the performance effect on a well-trafficked site can be significant.

In a clustered WordPress environment, the benefits are even greater; massively reducing the underlying processing power and memory requirements under load.

Although transient data is stored in the ‘wp_options’ table by default, they should never be directly accessed via a database query. Instead, they should be accessed via the simple API that is part of the WordPress core.

The simple addition of an API to get and set transient data means that additional performance can be gained by storing transients via in-memory cache solutions, such as Memcached. Through the use of plugins such as W3 Total Cache, it’s a relatively trivial task to offload all of the transient processing from the database.

The net result of employing a strategy which includes the considered use of WordPress Transients can massively reduce server load and rendering times and ultimately results in a site that can cope with large spikes in traffic load.


Improve WordPress media load times with an Origin Pull CDN

This blog entry describes how you can speed up WordPress media load times by using a CDN (Content Delivery Network). You can serve your static content faster, meaning that your site only has to be concerned with generating dynamic content.

Images, scripts and stylesheets can be automatically hosted by third-party CDNs and served to users without touching your own servers. This can seriously improve your own server loads, and makes a lot of sense!

1.    Choose your CDN provider

The first step is to choose the right CDN provider for you. CloudFlare offers free packages for new starters and there are others available such as AWS CloudFront. There are two main types of CDN “Origin Push” and “Origin Pull”. With this exercise we should use “Origin Pull”.

Once you have signed up and setup your CDN, you will be given a CDN URL like the one shown below:


This is the URL which will be used to fetch your content. For example: a request for the theme stylesheet would be directed to:


The CDN will then check if it has that file path already on its servers and also that the cache time has not expired. If not, it will fetch and store the file from the original domain. Otherwise it serves the content directly itself.

2.    Set Up WordPress to use CDN

WordPress can be configured to use the CDN for certain content. This can be done using a plugin; there are various plugins available but for this example we will use W3 Total Cache.

Install and activate the W3 Total Cache plugin and then inside wp-admin go to:

Performance > CDN

Here you can manage how the CDN works and what content you would like it to host. The most important part is the “Replace site’s host name”; this is where you should paste the CDN URL you were assigned during CDN setup.


Save the new settings and you are ready! W3 Total Cache will automatically replace your domain name with the CDN URL for your chosen content types.


WordPress Security Hardening – without throwing away the baby with the bathwater

If, like us, you manage WordPress installs where many thousands of users with high level permissions (super-admins, admins, editors) can login to the backend you will want to consider hardening security on the wp-admin side. However there is a delicate balance to be hit if you wish to avoid frustrating your users and increasing support costs for simple access requests.

In addition to Web Application Firewalls like Incapsula which are in place on our systems, at the WordPress level we have chosen two key ways of ensuring the backend is hard without being spikey…

WordFence – is rapidly becoming the de-facto standard security plugin for WordPress and it contains many options for actively scanning & protecting your sites. While it can be a bit wide in scope (recently added caching features, which in this writers opinion are not needed in a security plugin) it does have some very low level firewall features that can be really useful in stopping things like Russian hacking attempts. For us, two of it’s basic’s are fundamental;

1) ensure passwords are not weak

2) lockout protection for repeated password attempts

The importance of 1 cannot be overstated! The annual SplashData report on most common passwords reveals that perennial favourites “123456” & “password” still top the list – therefore it’s still very important to protect the users from themselves.

2 is getting increasingly important – we see thousands of brute force password attempts per day…

Wordfence Realtime Protection

The vast majority probing for the “admin” user password – as such you’ll always want to avoid using this username. WordPress uses this by default – but it’s really easy to change at install time & we heartily recommend doing so.

Our last line of defence is to add some protection should the WordPress backend ever get compromised. By default WordPress allows admins to edit files from directly inside the backend – this means an attacker could drop code onto the server to execute if they are able to get in. We have the file editor feature turned off on all our installs by adding one simple line to the wp-config.php…

define('DISALLOW_FILE_EDIT', true);

That’s it – some simple changes to significantly harden your WordPress backend without increasing friction to the users.