Detailed explanation of setting resource cache in nginx

I have always wanted to learn about caching. After all, cache plays a big part in front-end performance optimization. There are two types of cache: mandatory cache and negotiated cache. I have read many articles about the differences between them, but I have never used them in practice. I only know their meaning but don’t know how to set them. The lack of practical experience also leads to vague memory. Practice is the best teacher! Let me record my process of learning cache using nginx server.

Preliminary Study

First, I created a new index.html file and index.js file in the root directory of nginx . At this point, the nginx configuration file looks like this:

server {
 listen 8080;
 server_name localhost;
 location / {
  root /Volumes/myFile/nginx_root; 
  index index.html index.htm;
 }
}

Then we open the browser and access localhost:8080. Open the console and find two requests:

You can see that for the first access, the status codes of both requests are 200. Let's click on one of the requests to see the response header information:

As you can see, the response header carries Etag and Last-Modified information. This is the field used by the negotiation cache. It seems that nginx has used cache for us by default. Then we refresh the page again to verify without modifying the HTML file and JS file. If the negotiation cache is hit, the status code should return 304 Not Modified to us. I refreshed several times to observe the status code of the http request. The html file returns 304 every time. But the js file was initially 304 but later became 200 OK (from memory cache) . That is to say, every time the HTML file hits the negotiation cache, the JS file hits the strong cache (the priority of the strong cache is higher than the negotiation cache). Why does this happen? I searched on Baidu:

Why do some caches show 200 OK (from cache) and others show 304 Not Modified? It's very simple, just check whether the Entity Tag is removed. If removed, it will always be 200 OK (from cache). Without removal, the two will appear alternately.

So, what is the difference in the timing of the two triggers? 200 OK (from cache) is triggered by directly clicking a link or by typing in a URL and pressing Enter. 304 Not Modified is triggered when the page is refreshed or when a strong cache is set but the Entity Tags are not removed.

In contrast to my example, this is how I understand it: the index.html file refreshes the page and hits the negotiation cache, returning 304, while the js file is linked in the index.html file, so it hits the strong cache 200 OK (from cache). To verify my idea, I used the address bar to directly access the index.js file. Type in the address bar: localhost:8080/index.js. It does return 304 to me. Let's take a look at the request header at this time:

You can see that Cache-Control at this time gives max-age=0; and it also carries the relevant parameters of the negotiated cache. It seems that when the browser is refreshing, it will carry Cache-Control:max-age=0 to avoid hitting the strong cache.

nginx disable strong cache

Let's see what happens after trying to disable strong caching in nginx . Modify the nginx configuration file:

server {
 listen 8080;
 server_name localhost;
 location / {
  root /Volumes/myFile/nginx_root; 
  index index.html index.htm;
  add_header Cache-Control no-cache;
  # public can be cached by any object, private can only be cached by individual users and cannot be cached by proxy servers add_header Cache-Control private;
 }
}

After modifying the nginx configuration file, we restart the nginx server. At this time, visit localhost:8080

As you can see, at this time, both the HTML file and the JS file are 304 and both hit the negotiation cache.

Cache-Control: no-store

Disable all caching (this means that the response will not be cached). A cache will typically behave like a non-caching proxy server, forwarding a no-store response to the client and then deleting the object.

Cache-Control: no-cache

Force the client to send requests directly to the server, that is, each request must be sent to the server. The server receives the request and then determines whether the resource has changed. If so, it returns the new content. Otherwise, it returns 304, indicating that the resource has not changed. This can easily be misleading, leading people to believe that the response is not cached. In fact, Cache-Control: no-cache will be cached, but each time the response data is provided to the client (browser), the cache must evaluate the validity of the cached response from the server.

In fact, setting Cache-Control to no-store is the real meaning of not being cached. Then modify the nginx file and set Cache-Control to no-store to see what happens. Refresh your browser again at this point.

It can be seen that after modifying the nginx configuration file, except for the first time which was 304 (the browser just received the no-store information this time, and the request header still carried cache-related information), the remaining few refreshes of the page all returned 200. Neither the strong cache nor the negotiation cache is hit. Let's take a look at the http header information of the index.js file.

I didn't capture the entire picture here. In fact, the response header also includes Cache-Control: no-store . It can be seen that with the support of Cache-Control: no-store , even if the service returns the negotiation cache parameters in the response header, the browser does not bring the cache-related parameters when requesting resources. Therefore, there is no cache now, and neither the strong cache nor the negotiation cache will be hit. The resources of each http request are returned from the server.

Conclusion

This exploration has ended now. In fact, it is just a record of my learning. After practicing it once, I have a clearer understanding and cognition of cache. It is true that practice makes perfect. Later, I plan to write an article on how to use nginx to deploy front-end resources and configure related caches after the front-end is packaged using frameworks such as React.js or Vue.js. I will see if there is any point in recording it then.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.