There are plenty of options for developers and clients in terms of caching in WordPress. You may have heard of popular caching plugins like W3 Total Cache, CDNs like Cloud Flare, or managed hosting services like WP Engine that offer caching features, all of which promise to greatly increase page performance. In this post I'll go over why caching in WordPress is important, the different kinds of cache available to you, and how to bust the cache so that your visitors don't get outdated cached stylesheet and JavaScript assets.
Why should I use caching?
There are plenty of reasons to use caching in WordPress.
It's easy
One of the reasons to implement caching in WordPress is that caching functionality is built into WordPress by default. WordPress automatically appends a version query parameter to the stylesheet URI, which is a nice setup for developers to implement specific criteria for which to cache files. See more in the Different types of caching available section.
A common problem with many low-quality WordPress websites is that the site performance is terrible. This is common in all those trendy click-bait websites you end up visiting from social media networks. One of the reasons those websites are so slow is because they serve advertisements, but it is also highly likely that they have not implemented efficient caching to improve the user experience on their website. If you have a product- or service-based business—rather than one that generates revenue through advertising—you may care about the user experience on your website.
It lightens the load on your server resources to prevent Internal Server Errors
Better caching means that your server will be working less, which is important as your website scales and you get more visitors. You likely already know this, but if your server gets overloaded it means that your website could go offline. This can happen if the server-side script and/or database use too much memory and crash. A common error is one that says "Error establishing a database connection." This error occurs for a number of reasons.
- Invalid database credentials: The database host, credentials, or database user permissions for MySQL have been changed. If your website was running fine and you suddenly see this page and haven't modified the database credentials or the WordPress config, this is likely not the issue.
- Database corruption: It is possible that your database is corrupt and needs to be repaired. WordPress makes this fairly easy for developers to troubleshoot, but you may need to go into MySQL manually if this step does not work.
- Database server is down: MySQL can crash if it uses too much memory and the system kills it.
Implementing server-side caching will help alleviate stress on your server resources, which would prevent your application from using memory when it isn't necessary, which could save you from having to troubleshoot down time on your website.
Different types of caching available
There are a variety of different types of caching available, as previously mentioned.
Caching using asset version numbers in WordPress
WordPress ships with a built-in caching feature out-of-the-box. This allows you to assign a version number to your assets. Your visitors' browser then stores this version with the contents of the file in its cache. When the version your browser has is different than the version your website is serving, the browser will request a fresh copy with the new version number. In the source code of your WordPress website you may have noticed a path similar to: http://mydomain.com/wp-content/themes/my-theme/style.css?ver=4.6.1. This is WordPress' built-in caching functionality. The WordPress version is appended to the version query parameter by default, but developers can override it to be more intelligent. With the default option, the cache would only be flushed when you upgrade your WordPress core install, which doesn't happen as often as it should, and could likely happen less often than you update your website. This means that your visitors may not be seeing the newest styles and scripts when you want them to. Please see the section on Cache busting below for more information on solving this problem.
Caching using a Content Delivery Network (CDN)
There are services available called Content Delivery Networks. They provide a number of services, but one of the most valuable ones is caching. A CDN is an intermediary service that sits between your server and your visitors. Traffic goes through the CDN firstly, and then is routed to your server. It essentially acts as a highly-efficient middleman (or woman), and only goes back to your server when necessary. Common CDN providers include CloudFlare and CloudFront. These services can help protect your website against Distributed Denial of Service (DDoS) attacks, which are attacks with the sole purpose of overloading your server resources enough to make it crash. If a CDN is sitting in front of your website, the CDN gets this load, and they have intelligent measures in place to prevent the traffic from going through to your website.
Server-side caching using WordPress plugins on your self-hosted WordPress installation
When hosting your own WordPress website, you are responsible for ensuring that the server stays up, and if you have quick access to a web developer or systems administrator, then this is a great option to avoid the higher costs of managed hosting services. This has the lowest up-front cost, since you can download WordPress and a theme for free, and pay approximately $5-15 per month for web hosting or $5-$20 per month on a Virtual Private Server with root access. There are plugins available—a popular one being W3 Total Cache—which are developed to make WordPress efficient with caching. This plugin is great if you prefer to manage server-side caching at the application level rather than the infrastructure level. Setting up server-side caching using WordPress plugins on a self-hosted WordPress installation involves time and knowledge in many areas, including but not limited to software development, infrastructure, and networking.
Server-side caching in WordPress using a managed hosting service
If you would like to implement server-side caching but do not want to rely on a systems administrator or web developer to manage caching at the application or infrastructure levels, you can opt for a managed hosting service like WP Engine. Managed hosting services come at a higher cost (upwards of $30 per month) because there are teams of developers and developer operations guys and gals standing by to make sure your website never goes down. These managed hosting services can provide great value for clients whose websites experience heavy loads. Managed hosting services often have their own more intelligent forms of server-side caching implemented. These features are available as an alternative to managing caching with plugins on your self-hosted WordPress install. The benefits of going with a managed hosting service can include features such as:
- Very high and reliable uptime rates—some boasting as much as 99.9% uptime
- Preventative measures to protect your site from DDoS attacks
- Other security features, including preventing hackers from brute forcing your website
- Ensuring your WordPress core installation is the most recent at all times, which means that you have the latest security patches applied automatically without you having to do anything
Managed hosting provides great value, and, in my opinion is worth the additional cost if it is important that your website doesn't go down.
Cache busting to ensure users get the freshest assets
Client-side cache busting
As mentioned above, WordPress comes with client-side caching out-of-the-box. Currently it appends the WordPress core version to the file. It's much more intelligent to have the version code be generated using the file modified date to output, for example, this: style.css?ver=201612050921, which is a much more accurate representation of when you would like to update the file from cache. If the file has been modified and the version your browser tries to get is different than the version stored, then the browser will get the newer version. You can read the file modified date in your functions file using PHP.
Cache busting using a CDN
You can also ensure that your cache is busted when you deploy a new version of your site. Content Delivery Networks like CloudFlare have an API endpoint that you can hit to programmatically clear cache after a deploy. If you automate your site deployment (or deploy with one command), you can also add cache purging to the automation process. In order to clear your CDN cache programmatically, you will need to learn how to use the API of your CDN, which would likely involve creating/finding and using an API key and your website's identifier, and making an API request to the specific endpoint with instructions to clear the cache.
Cache busting server-side
Self-hosted WordPress
Depending on your setup, this could vary. If you use W3 Total Cache on a self-hosted WordPress installation, you will need to clear the cache through their interface in your WordPress dashboard.
Managed hosting on WP Engine (or similar)
If you used a managed hosting service like WP Engine, you can easily do that through their menu option in the WordPress dashboard. In the general settings, there is a button that says Purge All Caches. You can click that to purge the cache.
You don't always have to purge the cache on a managed hosting service, but if you encounter issues, you may want to:
We aggressively cache everything from pages to feeds to 301-redirects on sub-domains; this makes your site load lightning-fast for your non-logged-in readers. 99.9% of the time this is what you want, but every once in a while something happens where our cache should have been purged but wasn't. For example, some URL plugins change behavior without alerting WordPress. You use this button to purge all caches -- on our caching proxies, on the CDN, in memcached, everything.
Conclusion
Essentially, caching in WordPress is a great idea that is easy to implement. It will increase your site speed and reliability, which makes the User Experience of your website much more enjoyable. Caching using a Content Delivery Network offloads some work from your server, and client-side caching in the browser means your users only download the assets they need. Purging cache is fairly simple for a skilled developer to implement. If you have a WordPress site there really is no reason to not use caching—it'll make your life and the life of your visitors easier! Contact me if you'd like to discuss getting a WordPress website or improving your current one.
