I’ve always wanted to learn about caching because front-end performance optimization caching is a big part of it. There are two types of caching: mandatory caching and negotiated caching. Read a lot of articles about the difference between them, but no actual combat only know its meaning but do not know how to set, no actual combat also lead to memory is always very fuzzy, practice is the best teacher! Record how I learned to cache using the Nginx server.

A preliminary study

First I created an index. HTML file and an index.js file in the nginx root directory. The nginx configuration file looks like this:

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

Then our browser goes to localhost:8080. Open the console and find two requests:

You can see that for the first access, the status code for both requests is 200. Let’s click on one of the requests to see the response header:

As you can see, the response header gives us Etag and last-Modified information. This is the field used by the negotiation cache. It looks like Nginx has used caching by default. If we hit the negotiation cache, the status code should return 304 Not Modified. I refreshed several times to observe the status code of the HTTP request. The HTML file returns 304 each time. However, the js file that was originally 304 has been changed to 200 OK. That is, every time an HTML file hits the negotiated cache, a JS file hits the strong cache (which takes precedence over the negotiated cache). Why would there be such a situation, I baidu:

Why are some caches 200 OK (from cache) and others 304 Not Modified? It’s easy to see if you can remove the Entity Tag. Remove, always 200 OK (from cache). If you don’t remove them, they alternate.

So what’s the difference in timing? 200 OK (from cache) is directly click the link to access, enter the URL and press Enter to access can also trigger; 304 Not Modified is triggered when the page is refreshed or when a strong cache is set but Entity Tags are Not removed.

HTML file refresh page hit negotiation cache returns 304, js file was linked in index.html file, so hit strong cache 200 OK (from cache). To test my idea, I used the address bar to access the index.js file directly. Localhost :8080/index.js: localhost:8080/index.js

Cache-control gives max-age=0; It also carries parameters related to the negotiation cache. It seems that the browser carries cache-control :max-age=0 when it is refreshing to avoid hitting a strong Cache.

Nginx disables strong caching

What happens when you try nginx to disable strong caching. Modify 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_headerCache-Control private; }}Copy the code

After modifying the nginx configuration file let’s restart the nginx server. Localhost :8080

As you can see, the HTML file and js file are both 304 and have hit the negotiated cache.

The cache-control: no – the store

Disallow all caching (which is what responses are not cached for). The cache typically forwards a no-store response to the client, like an uncached proxy server, and then deletes the object.

The cache-control: no – Cache

Forces the client to send requests directly to the server, meaning that each request must be sent to the server. The server receives the request and determines if the resource has changed, returns new content if it has, or 304 unchanged if it has not. This can be very misleading and can be mistaken for a response that is not cached. Cache-control: no-cache is actually cached, but the Cache evaluates the validity of the cached response to the server each time it provides response data to the client (browser).

If you set cache-control to no-store, you will not be cached. If you set cache-control to no-store, you will see what happens. Refresh the browser again.

After modifying the nginx configuration file, the first time it is 304(this time the browser has just received the no-store information, and the request header still carries the cache information), and the other times it is 200. Neither the strong cache nor the negotiated cache was hit. Take a look at the HTTP header in the index.js file.

The response header also contains cache-control: no-store. As you can see in cache-control: No – under the blessing of the store, even in the response headers in service, please return to the negotiation of the cache parameter, but the browser in the request, does not take a cache of relevant parameters, so, there’s no cache, neither hit cache, also won’t cache hit consultation, the resources of each HTTP request returned from the server.

conclusion

This exploration is over now, in fact, it is a record of my study. After practicing it once, I really have a clearer understanding and cognition of cache. In the future, I plan to record an article on how to use nginx to deploy and configure the relevant cache after using react. js or vue. js framework packaging in the front end. I will see if it is meaningful to record it.

Finally, I would like to thank you for reading this article is not clear cache, please hit my article author sanmei, in the article about the cache field explanation part is directly copy his article inside.

Please correct any mistakes in the article.

After reading this article still not clear cache, please hit me