I co-organize the Calgary WordPress Meetup and last week we held an Online Site Clinic. The Site Clinic is one of the most popular things at our WordCamp and since Calgary isn’t having a WordCamp this year, we decided to bring the Site Clinic online with the Meetup group. It was a fantastic event; lots of great sites, lots of great feedback, and good engagement. I noticed caching was one of the biggest issues that kept coming up: either websites didn’t have it or if they did, it wasn’t set up correctly.
So let’s chat about what caching is and how it works on WordPress websites:
There are different types of caching:
- Server level caching
- Proxy caching
- Site level caching
- Browser level caching
You can have one, two, three, or all four levels of caching enabled; each comes with its own advantages and issues.
Server level caching
I like to think of this level as the base level. This is caching at the level where your website physically lives. Your server compiles the pages of your website and saves them so when someone accesses your website, it doesn’t have to compile your page from PHP templates to HTML in real-time. It just serves the compiled files.
A lot of managed WordPress hosts like WP Engine and Flywheel optimize their servers for WordPress-specific server level caching. It’s one of the biggest advantages of choosing managed hosting over basic shared hosting offered through Bluehost/GoDaddy/etc.
A small edit to note that that many plugins also employ caching on the server level, by saving your compiled pages and making them quickly available. 🙂 Thanks Topher, for reminding me to add this!
Proxy caching
Proxy caching typically happens one of two ways:
- ISP level caching
- CDNs (like maxcdn, keycdn, etc)
Many Internet Service Providers (ISP; the company you pay for access to the internet) have caching on a network level, they cache the sites their customers visit to create a faster experience on subsequent visits.
Sometimes you make changes to a website (install an SSL certificate, change some CSS, etc) and you can’t get it to show up on your browser, however, your friend on the other side of town just checked, or your spouse just checked on their phone with the WiFi off, and they see it. This often happens because they are using a different network, which may not have already cached the website, and is loading (and caching) the most recent changes.
CDNs (aka content delivery networks) are a network of servers around the web that you can connect your website to. When folks access your website, they access your website through the CDN.
So your visitors never directly access your website, instead they access a CDN server, which checks if it has a cached version of the page the visitor is trying to access. If it has a cached version, it rapidly delivers that to their computer, otherwise it visits the website, grabs the page, then serves that, and also caches it for next time.
Site level caching
Also known as page caching, this is what caching plugins often handle. When you install plugins like Fastest Cache, WP Rocket, etc, you’re activating site level caching. Unlike server caching, this happens entirely on your visitor’s computer. This is client-side caching.
These plugins manage the settings computers use to cache the pages people visit. The first time someone visits a page on your website, it gets saved (the HTML, the CSS, the scripts) in your visitor’s cache so when they next visit the page or any other page on the website that uses the same resources (the same CSS, the same scripts, etc), it loads faster.
By eliminating the need to talk to the website’s server for every page load, load times decrease and your visitor can access pages quicker. Site level cache stays on your visitor’s computer until your plugin or cache management system instructs the computer to refresh it. This is why expiring headers are important; they tell your visitor’s cache system when they should refresh the cache they have of a particular page or script.
Client-side caching is a very important part of WordPress caching, so even if your server doesn’t support or enable server level caching, or you don’t have a CDN connected, using a caching plugin to enable better site/page caching helps a lot.
The key thing to remember is that although plugins like WP Rocket, Fastest Cache, etc are compiling and saving your website as cache on the server, they make sure that cache gets added client-side in long term storage as well, as compared to browser-level caching, which is explained below.
Browser level caching
Browser level caching is cache that is saved in your browser’s cache. Like site level caching, this is also client-side caching, and it works basically the same way.
However, the difference between site level caching and browser level caching is that browser level caching only lasts as long as you have your browser open. Once you close your browser, this level of cache is emptied; it’s non-persistent. Whereas site level caching persists over multiple browser sessions.
If you have a simple WordPress website without any eCommerce features or anything that requires a lot of dynamic data being pulled in constantly, you can safely use all these levels of caching (or just some of them) without too much configuration or worry. However, if you DO take payments on your website, run a digital shop, etc, then each level of caching needs to be tailored to your website. This makes sure that things which need to be loaded every time load correctly and the things that don’t need to be refreshed with every page load (like jQuery or CSS, for example) can be efficiently cached.
Part of my job when I work with a client is just this: making sure that their website is cached most efficiently based on their website’s specific needs.
I hope that was a helpful primer on how caching works!
This is a newsletter I sent out to my list, get helpful articles like this straight in you inbox by signing up: