There are numerous caching plugins available for WordPress, in addition to caching mechanisms provided by your web host, for the latter you might not even be aware caching is enabled.
These can help speed up your website load times, however if you are using caching of any form, it can open up the potential to cause functionality and/or outdated page issues.
You’ll often see recommendations to enable caching to speed up your website, when you do this you’ll usually find a vast array of configuration options, and it’s easy to get carried away enabling all sorts of features, some of which you may not even know the full impact of.
Table of Contents
What is caching?
In very basic terms, if a page is cached then the code for that page is remembered, a user visits a page, if that page hasn’t previously been cached, then the page gets stored in the cache. Then, when another user attempts to access that same page, it gets served from the cache.
This can speed up the load time of the page and reduce usage of server resources, as the functions behind the scenes that generated that page originally aren’t getting called again.
The information in this blog post is related to server-side page caching. If you’d like to learn more about server-side vs client-side caching, and the various sub methods of these, see this article.
Doesn’t that mean cached pages become out of date?
Yes, depending on the lifespan of the cache, pages can be served which are out of date. Although, usually a caching solution will be clever enough to determine that a page was updated, and regenerate the cache for you. However, this is reliant on the caching solution used, and how it determines a page, or elements within the page, are newer than in the cache.
In the case of WordPress cache plugins, it may also rely on internal WordPress functions to determine a page was updated, and if you have an array of additional plugins installed they might not trigger these functions, that’s when an outdated page can continue to be served to users. Those outdated pages could result in someone seeing old information, out of stock products showing as in stock, etc.
Why caching can cause issues with WordPress nonces
In addition to the above, WordPress pages can contain “nonces”. A nonce is a security feature that helps protect against cross-site request forgery (CSRF) attacks. Nonces are unique tokens generated for specific actions or transactions within WordPress, ensuring that the request is legitimate and not a malicious attempt to manipulate or exploit the website.
Nonces can be found in various parts of WordPress, such as forms, URLs, and AJAX requests. They serve as temporary keys that validate the origin and intent of a particular action.
The issue is, if your page is cached, so are the nonces, and therefore if your page cache doesn’t get cleared regularly, the nonces in that cached page remain and might have expired when the user performs an action.
Read more about WordPress nonces.
Why you should consider setting cache lifespan to 10 hours or less
So why should you set your cache lifespan to 10 hours or less? It helps ensure the nonces remain valid.
Here’s an example: Let’s say you’re using a plugin which adds a custom submission form to a page, that form contains a nonce field for the reasons above. The nonce expires (by default around every 12 hours), however if your cache is set to clear every 30 days then that means for 29.5 days the nonce is expired, and in that time any user submitting that form is not going to be able to, depending on the error handling they might not even know there was an issue submitting the form.
To stop this issue from occurring, other than disabling caching entirely, the general advice is to set your cache lifespan to 10 hours or less. This is something that one of the leading WordPress caching plugins, WP Rocket, recommends in their documentation. This information generally applies to any caching mechanism used with WordPress, whether that be a plugin or caching features of your web hosting.
Furthermore, most caching plugins don’t cache for logged in users, so you, as the website admin, maybe testing the frontend of the website and not seeing any issues submitting a form, whereas your users who aren’t logged in are. Leaving you scratching your head as to why your website is broken for everyone else.
How to set your cache lifespan
This will depend on whether your caching is performed by a plugin, your hosting, or in some scenarios both. Before attempting to set your cache lifespan, be sure to investigate if/where caching is enabled.
To do this search your plugins list in WordPress for plugins which have titles/descriptions that state they are cache/performance plugins. Then ask your web host if they have any caching mechanisms enabled on your website. Once you know where caches are enabled you’ll then want to look through the associated documentation for a cache lifespan/expiry option and reduce it to 10 hours or less. You will likely need to purge all caches afterwards.
As an example, one of the most popular WordPress caching plugins is WP Rocket, the details on how to reduce the cache lifespan are provided here, at time of writing, this plugin has a default lifespan of 10 hours, but many other plugins have a higher default.
Each caching plugin will have different settings, so if you are unsure ask the support for the plugin used.
In regards to web host caching, the best option is to discuss this with your hosting support and request that they configure the caching lifespan to be 10 hours or less.
Why 10 hours or less?
This is because nonces last around 12 hours by default in WordPress, although while unlikely, another plugin/custom development could manipulate this expiry time.
Setting caches to expire every 10 hours or less ensures you are within the 12 hours, the 2 hour difference is just a failsafe. This may seem low, however there will only be a slow down in the load time of a specific page once every 10 hours.
Can I just increase the nonce expiry time instead?
Yes, it is technically possible, but isn’t generally done/recommended. If you do want to consider this, see the nonce_life filter hook.
I’m no cache expert!
I wrote this blog post based on my experience, i’ve seen multiple issues relating to expired nonces in WordPress where 99% of the time the issue is due to the page caching configuration.
I’ve searched for answers on how to get around this, aiming to keep the cache lifespan higher while not getting the nonce issue and couldn’t find a reliable solution. Some plugins offer “Edge Side Includes”, or ESI for short – but I struggled with getting this to work reliably too, it maybe something you want to investigate further. Hopefully in future there will be a better solution to this issue.
When tweaking your caching configuration always test on a staging/development environment before rolling out to a production website.