Has this ever happened to you? You go to a website, and it takes forever to load. Eventually, you see an error page. You hit refresh, and the site loads instantly. You write it off as a glitch in the matrix and move on.
But if you are responsible for a mission-critical WordPress site and your clients notice the same thing, writing it off isn’t an option.
So why does this glitch occur?
More often than not, this is a result of cold or expired cache. The way caching works is that your cache layer stores the HTTP response generated by the server and sends it to the visitors quickly. Other types of caches such as object cache, SSL cache work on a similar principle, and all of them have one thing in common.
All caches have an expiry date. Setting an expiry date on the cache ensures that your visitors see the latest content. It’s common to have the cache layer store the responses for up to 1 day if the site doesn’t change frequently.
But what happens when a visitor requests something that hasn’t had any traffic in a few days?
The cache layer doesn’t have that page readily available and needs to wait for the server to respond. If the server is busy, it can take longer than the visitor is willing to wait. When the server responds, the cache layer stores a copy of it. Now, if the visitor tries to revisit the same page, it loads instantly.
Another reason for the unavailable cache is WordPress plugins. Most cache plugins and cache management plugins have an option to flush the cache every time content is updated. While necessary, incorrect configuration of this functionality can result in flushing the entire cache (Frontpage, archives, all posts, sitemaps, and more) even on minor post changes. If the site has heavy traffic, this results in a sudden surge of uncached visitors resulting in a crash. This is referred to as a thundering herd problem in the industry. Unless you need to flush large chunks of the cache, fine-tuning this configuration is essential for an excellent performance.
All good marketing teams rely on URL parameters to track traffic sources and various campaign metrics. If you use CPC ads from Facebook or Google, each one of those visitors is assigned a unique click id as they land on your site. If your cache layer is not configured to account for these url parameters, each visitor sees an uncached version (potentially slow) of your site.
Here’s an example:
Cache layer has a copy of yoursite.com/blog/
Visitor requests yoursite.com/blog/?fbclid=2355453736765745
Since the cache layer can’t find this request, it requests the server to respond.
Another visitor requests yoursite.com/blog/?fbclid=7355453736765746, and the cache layer waits for the server again. Although both visitors are requesting the same page, URL parameters cause the cache to think these are different requests resulting in poor performance. Properly tuning cache keys helps resolve this issue.
These examples show us that merely having a cache system in place doesn’t guarantee better performance. Having a system in place to ensure that the cache is warm and available is essential for any high traffic website.
To programmatically warm site cache, you can use tools like headless chrome, selenium, or even good ole’ curl. Make sure that the cache is warmed more frequently than it expires to avoid the thundering herd or edge-cache timeouts on your site.