Customers who run a website often hear their programmer say “purge cache”, “refresh your cache” or “clear the cache before the test”
what does this actually mean?
Why do we need to do this?
Can’t our almighty programmer do some magic so we don’t have to clear cache all the time?
What about the site’s users? Should I also tell them to clear the cache?
In this article we will explain what the cache is, why it is good, why it is bad, and what can be done with it?
What is a cache?
The name cache is also called volatile memory or cache memory, describing a mechanism whose purpose is to speed up the operation of the site and the network traffic of the users, and in fact to provide them with a better browsing experience.
There are several different types of cache but the 3 main ones are:
client side cache –
server side (also called application) cache
cloud side cache – CDN cache or propagated cache
and each of them has a slightly different working method and goals.
Although the most common cache is the client side, let’s start with the server side cache:
websites have not been built in HTML for a long time.
In the past, each page was independent, we built it separately, we wrote the content into it and to change something in the content of the page we needed a programmer to handle it.
Over the years, management systems have been created, such as wordpress or magento, which make it easier to enter and edit content and allow website owners and website managers to update content themselves.
But how does it actually work?
In practice, we programmers write page templates today, and within the page templates there are content areas that reach out to the site’s database, and fetch the content for each area on the page.
The management system is basically the link between the site manager and the database. When we click the update button, we give the website system an instruction to update the information in the database for these content areas.
The next time user loads the page, the site system will again access the database and retrieve the updated information from there.
What is the problem with this method?
The access to the database (query) is relatively long, it takes time. The query time, and in many cases there is more than one query, slows down the loading speed of the page and impairs the browsing experience.
In fact, in most cases a page on a website can remain for weeks and weeks, if not months without any change in its content.
There is no good reason to access the database every time a user tries to load the page.
If we multiply the number of queries by the number of users on our site, or the number of page loads, we will find that all these calls to the database overload the storage server unnecessarily, because the content will not be different between user number 300 and user number 301.
So what is server side cache?
The solution is to produce static versions of our pages. Just like those HTML versions where all the content is already written in the code of the page. If already for the first user the website system accesses the database and pulls the information from it, we can write this information into a static file and submit it to the second and third users without the need to read the database again. This way we can provide a faster browsing experience, and ease the load on the server.
Cash of this type can usually be refreshed from within the site’s management system.
One of the most common plugins is wp-rocket and its cache clearing menu appears in the admin bar
The main problems with this type of cache are lack of updating.
Situations can arise where we have updated the content on the site, but the users still see old content and do not update because the application (site system) still remembers the previous content version in cache.
But this type of cache can be refreshed in the management system and actually rebuild the memory of all the website pages to update their contents again from the database.
Another common problem of the server-side cache is on ecommerce store sites.
Many e-commerce sites have content areas that are intended for the user and should be dynamically updated for each individual user.
This is where two new and slightly more technical concepts come in:
Both are related to the cache memory settings, and can be solved by a programmer.
A situation of under cache is that the management system does not save enough static assets, and actually continues with too frequent queries to the database, and it is better to add additional static assets to the cache memory to improve speed and loads on the server.
On the other hand, it is advisable not to reach a situation of over cache because for example the shopping cart, the checkout page, and the thank you for your purchase page – they are not static pages.
They have static parts such as their structure, but the information is personal to each user, because the composition of the cart, the coupons, the discounts, the customer’s address – all these are personal data that should not enter the cache memory.
One of the most embarrassing failures is, for example, the appearance of the administration bar for normal users who are not connected to the administration system.
It is difficult for a programmer to find such faults because he is usually busy with the website when he is connected to his management system.
Overcache failures will only be seen during the QA – end tests that are conducted after the maintenance or development sprint.
What is cloud side – CDN cache or propagated cache?
In direct continuation of the server side cache – in many international websites the storage infrastructure is a cloud infrastructure whose purpose is to spread the website to as many geographical areas as possible.
For example, if my storage server is in Israel, but I have many clients in Europe, or in the US – a cloud solution allows me to create static versions of my website on additional servers that will be closer to the target audience, and therefore allow them a faster browsing experience, with the click of a button.
The static versions in the cloud are updated against the main website – the one that is stored on the server in Israel, and once in a while the information is pulled from it again and the static version is updated.
Here, too, there are exactly the same problems that exist in the server side cache, because again we are talking about static versions of the site, and even more so – there may be a situation where users from different geographical areas will receive a site with a different update level because the European cloud has been updated in the last hour, and the American cloud is still No.
In this case, refreshing the CDN cache will require logging into the CDN’s management system and the need to purge the cache.
Many cloud systems and cache plugins allow the connection of the two systems to synchronize the information in a more convenient and better way. For example, wp-rocket supports several large and well-known CDN networks, including cloudflare and rocketCDN.
Other cloud CDN networks have invested in plugins whose purpose is to give the instruction to clean the cache from the site’s management system and save the site manager the need to enter the network’s management system for the purpose of the purge cache operation.
However, clearing the cache at the cloud level requires more time than clearing the cache in the application, and it will usually take several minutes for the update to catch up (propagate) in all the geographical areas to which we serve the site.
Client side cache –
is usually the cache that the programmers mean when they ask the client or the site administrator to “clear cache”.
Similar to cache on the server side, or on the cloud side – here too the goal is to save a “memory” of static assets on the client side to save access to the storage server.
In this case the browser does not save the content itself, but there are still things on the site that do not change when you browse from one page to another – for example the design of the site – the style.css file remains the same on different pages of the site.
The logo of the site, or the favicon, fonts, shape of buttons, visibility of form fields and more – all these may change very rarely.
In practice, after the user has browsed to one page, he already has all the design settings of the site and shared assets, and there is no need to reload them.
On the other hand, if the site manager asks the programmer to change a font, or to update something in the site’s visibility – those users who are currently browsing the site, or who have loaded the site over the past few days, may not reflect these changes because they still have different visibility settings in their client side cache memory.
Should site users be instructed to clean cache?
This problem can only occur with those who visit the site very often – as mentioned, the browser erases its memory about the site after a few days.
In general, it is not of critical importance if the site appears to the end users with an “arial” font or another font, as long as the information they receive is accurate and up-to-date.
Mainly under campaigns, most of the customers who enter the site will be users who have not visited the site in the last few days or have not visited the site at all, so they will not have this problem.
On the other hand, “frequent” or “live” users who want to see the design change will have to purge the cache manually because the browser only clears this memory after a few days when the user does not access the site.
Among these users are also the site administrators themselves who visit the site very often. In order to reflect the design updates, it is necessary to delete the cache memory on the client side. Then the programmer will tell you to “clear cache and check again”
this cache, the programmer has no possibility to refresh or monitor because it is part of the operating system of the browser of each individual user. The programmer also cannot know how long each user’s browser keeps this information in its memory.
In addition to clearing the cache in the browser, in order to check the new visibility, you can also enter the website from another browser, where the design settings are not yet saved in the cache memory, and for that matter, incognito browsing can meet this requirement, but to reflect the design updates in the website administrators’ normal browser or mobile devices will need to clear cache in each and every browser separately.
To read more about cache and how to purge it – click here