I believe that many front-end children’s shoes are not too unfamiliar with browser cache, but if there is no systematic summary, it may be difficult to understand in a few words. How to answer it perfectly is a question worth thinking about.
Of course, we can’t master it just to deal with the interview, but we should reserve it as a skill and use it flexibly.
1、 Why cache
1. Cache can reduce user waiting time and improve user experience;
2. Reduce network bandwidth consumption
For the website operators and users, bandwidth represents the cost, too much bandwidth consumption, all need to pay extra fees. If the cache can be used, it will only produce very small network traffic, which will effectively reduce the operating costs.
3. Reduce server pressure
After the validity period of network resources is set, users can reuse the local cache to reduce the request to the source server and reduce the pressure on the server. In addition, the crawler robot of search engine can reduce the crawling frequency according to the expiration mechanism, and also can effectively reduce the pressure on the server.
It should be noted that improper use of the cache may lead to “dirty data” and cause user data exceptions.
2、 Common cache types
Browser cache is divided into strong cache and negotiation cache.
1. Expires: a time string in GMT format, representing the expiration time of cache resources
Expires also needs to be configured on the server side (the specific configuration depends on the server). What expires adds is the expiration date of the resource. The browser will compare the expiration date with the client time. If the expiration time has not yet arrived, it will read the resource from the cache. If it has expired, the browser will judge that the resource is not fresh and needs to be retrieved from the server again.
In this way, it can be read directly from the browser cache without the need for the server to determine whether it has been cached, thus avoiding the HTTP request. It is worth noting that there may be inconsistency between the client time and the server time in the expires time.
It is recommended to use expires in combination with cache control. It is common to use expires with cache control in large websites.
2. Cache control: Max age strong cache uses its max age value to determine the maximum life cycle of cache resources. Its value unit is seconds.
The cache control attribute value is configured on the server side. Different servers have different configurations. The configuration of web server Apache, nginx, IIS and application server Tomcat are not the same;
1. Last modified: the value is the last update time of the resource, which is returned with the server response
2. If modified since: judge whether the resource has been modified during the two requests by comparing the two times. If not, the negotiation cache will be hit.
3. Etag: the unique identification of the resource content, which is returned with the server response.
When the web server responds to the request, it tells the browser the unique identity of the current resource on the server
Note: http does not specify how to generate Etag. Hash is an ideal choice.
The server compares if none match of the request header with the Etag of the current resource to determine whether the resource has been modified between the two requests. If not, the negotiation cache is hit.
3、 Cache process analysis
After reading the above concepts, let’s take a look at the caching process? Let’s take a look at the following picture
As shown in the figure above:
1. The browser will first check whether the strong cache type (cache control or expires) is valid;
2. If the strong cache is hit, the cache resource is obtained directly from the local;
3. When the strong cache fails to hit, the client will send a request to the server. The server will verify whether the resource hits the negotiation cache through other request headers, which is called HTTP revalidation. If it hits, the server will return the request, but not return the resource, but tell the client to get directly from the cache. After receiving the return, the client will get the resource from the cache;
4. The strong cache will not send the request to the server, but the negotiation cache will send the server request;
5. When the negotiation cache fails, the server will send the resource back to the client.
It should be noted that:
1. The common feature of strong cache and negotiation cache is that if the cache is hit, the server will not return resources;
2. When F5 refreshes the web page, it skips the strong cache, but checks the negotiation cache;
3. When the page is forced to refresh by Ctrl + F5, it is loaded directly from the server, skipping the strong cache and negotiation cache;
4、 Will not cache
Of course, not all requests can be cached. The requests that cannot be cached by browsers are as follows:
1. The HTTP header contains cache- Control:no-cache , pragma:no-cache (http1.0), or cache control: Max age = 0, etc. to tell the browser not to use the cache request;
2. Dynamic requests that need to be determined by cookie and authentication information can not be cached;
3. Request encrypted by HTTPS security;
4. Post requests cannot be cached;
5. Requests that do not contain last modified / Etag or cache control / expires cannot be cached;
5、 Small story, big truth
The whole concept has been described above, but it is not vivid enough. Let’s understand it vividly through several small stories
Story 1: last modified
Browser: Hi, I need it jartto.min.js If this document was modified after last modified: fri Feb 15 2019 19:57:31 GMT, please send it to me.
Server: (check file modification time)
Server: Oh, this file has not been modified after that time. You have the latest version.
Browser: great. I’ll show it to the user.
Story 2: Etag
Browser: Hi, I need it jartto.css Does this file not match the string 3c61f-1c1-2aecb436
Server: (check Etag…)
Server: Hey, my version here is 3c61f-1c1-2aecb436. You are the latest version
Browser: OK, then you can use the local cache
After reading these two stories, do you have a clearer understanding of negotiation caching.
Editor in charge: CT