If you bought milk in a store, you can understand how server-side caching and browser-side caching work.If you are an active Internet user (and this is most likely the case), you constantly use caching, but you may not know the backstage: when and how it works.
From a developer's point of view, caching simplifies the creation of high-performance web applications and web servers: you do not need to constantly optimize servers overloaded with thousands of requests — you just implement caching protocols and it becomes much easier to live.
When caching the page load time decreases from 2 seconds to 1 second ... which is not very impressive, right? But you can't do without it when you have to process requests from a large number of users.
Using caching in one of my web applications, I realized that just walking through the terms is not the best way to explain this approach. It occurred to me that a good analogy would be the path of milk from the farm to the refrigerator.
To understand my explanation, you need to know a little about the
basics of web servers . Let's get started!
Transferred to AlconostWhat would the Internet look like without caching?
Before we get to caching, let's think about how the Internet would look like without it. Imagine for a moment that you live in the XVIII – XIX centuries. in the countryside. You have a farm, but no fridge. You keep several cows, but their milk quickly deteriorates, and therefore it is very difficult to benefit from it.
By the way, in some places people still do not have refrigerators: they either drink fresh milk at once, or
mix it with grain and allow it to ferment - an interesting approach, isn't it?
In general, you would like to sell milk to other villagers. But they will have to drink it very quickly. Suppose a cow can produce ten liters of milk per day. This means that if too many people suddenly come to the farm for milk, you will have to ask them to come back the next day.
And this is not the case when you can just start a couple more cows and expand, because you have a limited purchasing base: only residents of one village buy milk. Therefore, there are well-defined limits.
Without caching, you are limited by the processing power of the servers. Caching is used to load static resources such as:
- Images,
- CSS,
- static html files
- Javascript files
By default, for each incoming request, the server must send a new response. But a page load request can actually mean four separate requests — one for each of the categories above. If we take into account that image files are usually quite voluminous, then a large number of users from all over the world will easily reload your servers, and the pages will take longer to load.
Ideally, I would like to reduce the load on the servers, somehow preserving the answers to common requests. The server does not have to handle each new separate request - the response will be received from the cache. Of course, you can always fork out and add more servers, but this can lead to an uncontrolled increase in costs.
Server side caching
Let's go back to our cows. Do you know what would facilitate the work of our dairy farm?
Shop with a fridge!
Residents will no longer need to come to the farm and immediately drink milk, because it can be safely stored for several weeks.
The store takes the load off the farm: now cows do not need to be disturbed for every customer. The store is in charge of meeting the demand, and all you have to do is milk the cows daily. And another plus: the inhabitants of the surrounding villages can now buy the milk stored in the refrigerator.
The server-side cache will, like the store, handle popular queries and deliver content much faster and more reliably.
The picture above shows a
caching proxy server : it stores static files that are used to respond to common requests. This server intercepts such requests and quickly gives an answer that allows you to remove the corresponding load from the main web servers.
At this point, you may already have questions:
- How to determine the "popular" query?
- How long are replies stored in the proxy cache?
To explain this, we need a more detailed guide to setting up caching, but now it is important for us to know about one important concept -
freshness . There will be different files on the caching proxy server, cached at different times, and he needs to decide whether these files should still be issued. This will depend on the
caching policy .
Which also resembles the storage of milk in the store. The store manager needs to decide how long the milk will lie before it is thrown away. Caching proxies measure the effectiveness of their work by the
percentage of caching - the proportion of content that can be issued through a caching server.
Content Delivery Network
So, we have one grocery store selling your milk. Already not bad, but residents can buy milk only in one local store, and hardly anyone will come to him from afar. To expand production, you need to sell milk in more stores.
So, you start to deliver milk to other stores and thus satisfy the demand in a much larger geographical region. This is similar to the content delivery network (CDN) —proxy servers located around the world (such as those discussed above).
As an end user, it may seem to you that high-speed Internet allows you to download most sites very quickly. However, this is primarily due to the use of a CDN for fast delivery of static files.
If you are in England and are trying to upload a file cached on a server in Khabarovsk, the answer will come with some delay: the signal will take time to travel thousands of kilometers of cables. Therefore, a local caching proxy server in the UK will allow you to load the site faster.
In this way, your servers can send a copy of static resources to each of the proxies on the CDN so that they process local requests until the resources are no longer “fresh.” Popular CDN service providers are Rackspace, Akamai, and Amazon Web Services.
Browser caching
So now people from all over the country (and even the world) can bring home the cold milk produced on your farm. One problem remained: they could not store milk at home, so after the purchase they have to drink it quickly, and after a new batch they go back to the store. It turns out that such a system is still not very convenient for buyers.
We will save the refrigerator!
Having a refrigerator, you can store milk at home and do not run to the store every time. In terms of caching, this is a completely different place to store static resources, since it is on the client side (in other words, on the computer where the browser is running), and our proxy server was in a remote location.
This approach is not only convenient for the user in the case of frequently visited sites such as Facebook or Amazon, but also allows these sites to save on server expenses due to the smaller number of requests processed.
And here it is important to note that milk in the refrigerator DOES NOT APPEAR ITSELF! All the same, you need to make the original request, which will reach the server or proxy server, and only after that you can cache some files locally.
How does the browser know when to request new files from the server? After all, you need to somehow update the local files.
Just as milk producers put an expiration date on the packaging, so the servers add a specific identifier to the HTTP response header. For HTTP caching, there are actually
four different systems . The scenario described above is very similar to the “shelf life” method. However, in the case of some other methods, you need to send a request to the server before issuing the cached file.
When to start using caching
Suppose you are creating your first web application. As long as you do not have thousands of users, you most likely do not need to worry about caching protocols: the cost of server operation will be quite low without it. However, as the user base grows, you will need to implement caching as well - if you want the application to load quickly.
Take, for example, Heroku - a great tool for deploying the first web application. However,
to implement caching you will have to use a separate service — for example, CloudFront from Amazon or CloudFlare — and it will take more time to study this.
You can notice caching on the browser side when you try to reload the page and get new static resources, but the page does not change, no matter how many times you refresh it.
Usually the reason for this is the work of the browser caching protocol. To bypass the browser cache and request new resources from the server, you can click
Cmd + Shift + R (if you have a Mac) or
Ctrl + Shift + R (on a PC).
About the translatorThe article is translated in Alconost.
Alconost is engaged in the
localization of games ,
applications and sites in 68 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.
We also make
advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.
Read more