Websites, web shops, applications … basically just about everything needs to be loaded and displayed fully within half a second (400ms is a goal that many tools use). There is a lot going on to get this done “under the hood” if it concerns a more complex whole. Often people turn to a cache solution.
What is cache?
Before I discuss when you should actually use caching and not. First, let’s make clear what caching really is.
Caching, also called cache, is an alternative form of data storage that can prevent the same information from being downloaded again or having to perform complex calculations again.
Many browsers already work with their own caching. Images, style sheets and static web pages are stored on the user’s system as temporary internet files.
That is until the moment that changes occur, until then these files do not have to be retrieved again from the internet.
Types of caching
But caching is possible in many different areas. It’s not just about the browser. Consider, for example, server side cache.
Within caching you have all kinds of different forms to give you an example;
- Client-Side Caching
- Browser Caching
- Server-Side Caching
- Database Caching
- Object Cachimg
- Opcode Caching
- Page Caching
- Content Delivery Network (CDN) Caching
And then I will probably still forget a few, but in short, a lot is possible with a view to caching. In addition, in this item I choose not to delve too deeply into any form, otherwise that would really be too technical.
Advantages of cache
Every form of cache has its own form of advantage. But in essence it comes down to the following for all forms; Because information is available faster, often in the form in which it is also used in the application, the program becomes faster to use.
Speed
The faster it is used, the happier the user, the better the experience, the greater the chance that the user will take a certain action (conversion).
So when it comes to cache, think in terms of speed. Do not underestimate how heavy speed now weighs on users. If a website does not respond within 2-3 seconds, the experience is bad and your potential customer is gone.
Everyone has almost heard of the 2012 Amazon study (https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales) where they concluded that 1 second longer they loses them 1.6 billion dollars in sales.
But a bit more recent
Amazon has added a gradation to that a lot more recently. Because, of course, Amazon is not standing still; but every 100ms that Amazon loads slower, it saves 1% on sales (https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-laatcy-cost-them-1-in-sales/)
In short, speed and caching are important when it comes to accessibility and revenue.
Disadvantages of cache
As John Cruyff could say so fittingly;
Ieder voordeel heb z’n nadeel
Translated that comes down to; Every advantage in return has a disadvantage.
And where cache has many advantages, there are also a few things that you can see as a disadvantage.
Cache can be confusing
Caching must be set up in a good way and by that I mean that invalidating (cleaning up) the cache must also be done in good fashion. For example, if you have a Wordpress website and you add a new post or you update a post, everything related to that post may have to be emptied in terms of cache.
Depending on the platform you use, there may or may not already be the necessary logic for that.
But caching is also confusing because it also exists outside of the server and application. By that I mean mainly client-side and browser caching. Especially since it has become a lot more stubborn in recent years (you have to empty your cache HARD much more often than before to really get rid of it)
Cache for developers … is cumbersome
As a developer I know only too well that working in an environment with cache can be quite challenging. Especially if you have to examine scenarios in which non-logged in users are served a cache and (perhaps) as a logged-in user you do not get this.
That is why cache is highly recommended if something has ended up on a production platform after extensive testing and finalization.
However, for being able to develop to an environment that uses production caching, it is much more practical to have a testing / staging / acceptance environment where cache is not a factor.
Because you don’t want to make your developers crazy about cache …
Is cache always a solution?
But do you always have to use a cache solution to overcome accessibility / speed problems? I personally believe that this does not have to be the case
Cache is also often used too often to relieve an underlying problem. I usually call that a ‘plaster solution’. By that I mean that you stick a plaster over the wound but you have not treated the wound itself. So you don’t actually solve the underlying problem.
I believe that you first have to make sure that the theme, system, server etc. is running properly before you start using the addition of caching. Only in this way will you get a truly optimal / efficient working whole.
If you first tackle those other aspects properly, then it may even be that you do not need any caching at all for a well-functioning platform.
Friend or foe?
So friend or foe, cache is useful and in many cases very welcome. But treat it well like a friend or it may eventually become an foe.
Therefore let the caching be set up by experts who know how to handle cache well.
I think that I am well aware of that in view of my experience from the hosting, support and development sectors. After all, I still do it now for my own major projects such as NintendoReporters (https://www.nintendoreporters.com/).
