Insights All you need to know about caching

If you look after a website or manage its content, you have probably been asked to “Clear your cache”, if you’re seeing something not quite right or you’re not seeing the latest changes on your site. For the majority of people, this means reloading your webpage and/or going to your settings in your favourite browser and clicking the magical button that is “Clear cache”. You might also be doing something similar to hide your internet activity from a significant other, but this isn’t about your sketchy browser history. This is a shallow dive into the deep waters of caching and the many different types of caching that may make you wonder when next you’re asked to “Clear your cache”, which one?

What is caching?

In this case, and in many cases involving IT professionals, when we say cache, we’re referring to a technique that stores data or files in such a manner that we can retrieve repeated information at faster speeds. Often bypassing heavy computational costs like cutting down database queries or server-side processing. In terms of websites, this means that content is served to your users quicker, which is a pretty big deal; see this article for more information as to why!

How does it work?

Imagine a super complicated sum; let’s say, 26756 * 8. The clever clogs among you have probably worked out that that is 214,048. Well done. But for the less intelligent members of the audience, you will probably (understandably) reach for a calculator to work this one out. But if I were to repeat the question, you’d be able to tell me the answer by just looking at your calculator. Significantly reducing the time it took to get the answer. This, in a very simplified nutshell, is how caching works.

Why does the cache need to be cleared?

Content on a webpage can be changed in a number of ways; the CMS has saved some new content, a developer has updated the code or even the date or the time of day can affect the content of a page. This would mean that the webpage we previously stored for faster access would be out of date and any subsequent retrievals of this cache would bring back the wrong information. So, sometimes a message needs to be sent to the caching system to bypass the next request to the cache and retrieve new information, which would then cache the new information.

Full disclosure: the following is slightly more techy. Proceed at your own risk!
 

Types of caching

Delving slightly deeper into the world of caching, here (very generally) are some categorisations of caches.

Browser
The one everyone refers to when they say “Clear your cache”. The browser very kindly caches websites that you’ve previously visited on your computer’s hard disk, so that instead of firing off lots of web requests to the website’s server, it just has to look in your hard disk, resulting in much quicker website retrievals. By default, this is enabled on all browsers but it can be disabled in a number of ways, if you always need to grab the latest version of the web pages that you visit.

Application
Most websites are built on top of a CMS (see more about the benefits of content management system’s) these days and the majority come with a way to cache the content created this way. This can range from micro caching (e.g. individual blocks) or macro (e.g. entire page HTML). These are usually very custom caching techniques depending on the CMS of choice, but nearly always come with a way, via the CMS, to clear the application cache. So, if you find that you’ve cleared your browser cache and the page content is still not appearing as you’d expect, try clearing the cache via your CMS.

Server/Service
This is a broad and varied category of caching, as there are many different types of caching out there. To name but a few that you may have heard of...

• CDN’s (e.g. Cloudflare, Cloudfront) 

AKA content delivery networks, these servers will cache your website and then serve that content close to the user’s location. Basically, let’s say your web pages are stored in two servers, one in the US and one in the UK, if your user is coming from the US, the website will retrieve cached data from the US server, rather than the UK to reduce the time it takes to retrieve that data. As the further away the content is served from the server, the higher the connection latency.

• Redis 

A server designed specifically for caching data. Specialises in retrieving information based on key/values pairs.

• Service workers 

Service workers are pieces of Javascript that can be added to your site by your developers. They can provide a lot of value, with things like offline pages, but they can also cache your site for extremely fast retrieval.

Typically these caches are a lot harder to manage and would require experience from your developer to action. But the benefits to having any of these can be huge, especially if you have a high volume of traffic.

So should we cache?

Browser caching and application caching, almost always should be, yes! You’ll find that most experienced developers will provide this functionality for you out-the-box as standard. But what about server/service level caching? This very much depends on the client, scope and budget. Not every website will be cost-to-performance effective by throwing high-level caching functionality at them. There’s also a higher level of understanding that’s required to run these services, then with your typical caching so they’re harder to create and typically more expensive to run. Some clients/scopes may even have security to consider where caching the wrong data could result in a breach of data. Although these security issues can be mitigated, they’re enough of a concern for some to not go jumping into using these high-level caching services.