One of the things that pops up on a daily basis is the issue of caches. We do a lot of WordPress sites and anything more than a few pages really benefits from a cache plugin to improve performance.
On a WordPress site, pages don’t exist until they are called up by a browser. When a page is requested WordPress goes on a long journey around its database to pull all the pieces of the page together, all the content from the user and all the images and scripts. Then it puts them into the right order, adds styles and, finally puts it up in front of the viewer. Once they’ve stopped looking and leave the page, the page is just gone. The next next time anyone else needs to see that page it has to go through the same process again. Web servers are great at doing this kind of thing but if it’s a popular site that’s a lot of work top do every time a page gets hit.
WordPress caching plugins came in to try to overcome this. They cleverly capture the page which has been constructed and given to a users (rendered) and save it, almost like taking a screenshot. Next time anybody goes for the same page they get redirected to the saved, pre-rendered snapshot rather than making WordPress build it all from scratch every time. The performance improvements can be dramatic. The first time somebody loads a page is the only time the page is constructed from its parts – every time after that everybody else gets the saved snapshot. With some plugins you can even set them to generate these snapshots in advance (priming) so even the first person to view the page gets the performance advantage.
It’s not just WordPress. Web browsers have always done this, initially to save users on dialup modems the pain of loading the same thing over and over again through a slow connection. A browser downloads a page and all of its images into a cache area on your own hard disk. That way when you jump around a website, the pages you’ve already seen and the images you’ve already loaded come from your computer rather than a far away country, so the speed savings are obvious.
Most of the techniques mentioned above are related to the web browser (Chrome, IE, Safari etc,) being used and WordPress. But web hosts themselves can use a caches. For example on Linux servers running an Apache as web server hosts often add a module known as “Mod Expires” (https://httpd.apache.org/docs/current/mod/mod_expires.html). This adds and instruction to web pages which tells the user’s browser to keep the files from this page stored on their local device to be used the next time the website is reloaded, but it puts a time limit on how long these files should be cached. The time limit becomes more important if your site is updated regularly. Because you can’t force users to clear their caches when you want them to, setting the files they have in their cache to expire like this is a good way of forcing it to happen. The art is deciding the expiry time – too long and your users never see the site has been updated but too short means unchanged files are downloaded unnecessarily more frequently.
Content Delivery Networks
Content delivery networks (or CDNs) like MaxCDN or CloudFlare offer an extra boost by using a cluster of external servers to host copies of the site which are used instead of the site’s actual server. These copies (caches) have to be cleared by using the CDN’s own control panel which will then request the cluster network to remove cache files and get another fresh copy of the website from its “original” physical server.
This is a more expensive and technically complicated way of caching as you need a set of extra servers but is used successfully by large, international sites like Amazon and Facebook, etc. as they can locate the servers around the world to allow users to get the nearest local version. They can also upgrade the cluster by adding more servers whenever they need to.
The problem with caching is when pages get updated. How do you know if users are looking at the very latest version of a page or a cached version from last week? This is a huge problem for us. Pretty much every update to a website gets lost to a cache somewhere along the way and it’s probably our number one topic of conversation with clients after an update. As we’ve seen, there are so many places a cache can be and so many ways of caching that it’s amazing anybody actually ever sees an update. From web browsers at the users’ end via the office routers, ISPs equipment, website caching and all the way up to the server itself. Each one of these can try to help by storing common pages or parts of pages.
Ironically, our clients look at their own websites so often during updates that they are bound to get a cached version whereas their viewers who might never have been on the updated pages usually get a fresh version.
How to Get Round It
The first thing to do is clear your web browser’s cache. This kind of cache happens on all websites, whatever they have built in. Each browser has its own way of overriding this behaviour and it can usually be done with a keyboard shortcut rather than going through menus. Here are a few of the most popular:
- cmd + R reloads the page.
- cmd + option + E clears the entire cache.
- cmd + option + R forces a reload from the server (no cache).
Using the last two in sequence usually seems to do the job best.
- F5, ctrl R (Windows) or cmd + R (Mac) reloads the page.
- Shift + F5 , ctrl + shift + R (Windows), cmd +shift + R (Mac) forces a reload from the server (no cache).
- F5, ctrl R (Windows) or cmd + R (Mac) reloads the page.
- Shift + F5 , ctrl + F5, ctrl + shift + R (Windows), cmd +shift + R (Mac) forces a reload from the server (no cache).
Explorer / Edge
- F5 or ctrl + R reloads the page.
- ctrl + F5 forces a reload from the server (no cache).
Once you’ve got control of your browser you need to look at the other end of the chain. Whilst the tips above work for any website, here are some notes specifically for WordPress site owners.
Look in the settings of your cache plugin for ways of disabling or clearing the cache. Most plugins have a set of controls similar to those described below, although they all give them their own names.
Purging clears the entire cache by deleting all of the stored pages. The button to do this can sometimes be labelled “Clear Cache” or “Empty Cache”. Cached pages are removed and then rebuilt the first time a viewer looks at them.
Priming simulates somebody going through the entire site looking at every page, forcing a cached version to be created for each. The effect is that every page is already cached before anybody sees it. The downside is that on a large site, this can take a long time so should be used with care. Used in conjunction with purging guarantees the entire site is fresh.
Per-page clearing. Several plugins add a button to WordPress’ editor (usually near the “Update” button) which allows you to delete that page or post from the cache specifically. This is useful if the update or post is important or its previous version has information that would be inaccurate. It avoids having to clear and regenerate the entire site’s cache every time you make a small update.
Scheduling. The site’s cache is automatically cleared out at a set interval. This mops up any uncleared pages. If you have the option of setting a time of day for the clearout, check your site stats to see the time of day/week when your site is quiet and set it for then to minimise the impact on users.
Admin override. Useful for site owners and developers. Your cache plugin may have a setting which disables the cache for users who are logged in as site admins but leaves it on for everyday visitors. Just log into the backend as normal and then, without logging out, browse the frontend of the site – you should get the freshest versions of all posts and pages (at the cost of reduced performance).
Outside of WordPress, you can force users to re-download files by simply changing filenames to fool the browser into thinking they are new. This is often done by adding a fake query string to the end of a link. For example, https://azzure-creative.com/that-syncing-feeling/ and https://azzure-creative.com/that-syncing-feeling?q=456 go to exactly the same page, but a browser will think they are different due to the extra garbage at the end after the question mark, and so will download the original from the server rather than use its own cached copy.