1. Why cache?

  1. Advantages of caching:

1) Accelerate the browser loading speed of web pages, optimize user experience, so that users can open our web pages more quickly;

2) Reduce the number of visits to the server and lighten the burden on the server;

3) Save bandwidth (save money… , because a lot of bandwidth services are actually charged by traffic, the same users can also save 4G, 5G traffic… Also saves money)

2. The downside: If the resource is always cached, users can’t get the latest information when the resource changes! So cache is good, but don’t mess with it. Caches are classified into strong cache and negotiated cache

Strong cache

Strong caching is the forcible caching of resources

Strong caching is controlled using the Expires and cache-Control fields in the HTTP header

Expires The value is an absolute time, which represents the expiration time of the resource, meaning that the cache is always valid and the data in the cache is always read before this time. However, there is an obvious drawback: because it is an absolute time, cache invalidation can occur when the server time deviates from the client time, such as when a user arbitrarily changes the local time.

Cache-Control Http1.1 has been added to cache-control, and max-age=2592001. Max-age =2592001; max-age=2592001; There are other values besides mas-age:

1) Public /private: public indicates that both client and proxy servers (such as CDN) can be cached. Private (default value) indicates that only client can be cached.

2) no-cache/no-store: the contents of the no-cache client cache, but whether to use the cache needs to be verified by the negotiated cache; All contents of no-store are not cached, that is, no strong cache is used, and no negotiated cache is used.

PS: Expires and cache-control can be enabled on the server at the same time. Cache-control takes a higher priority when both Expires and cache-control are enabled

Negotiation cache:

Negotiation cache is a process in which the browser sends a request to the server with the cache id after the cache is invalid, and the server decides whether to use the cache based on the cache ID:

The negotiated cache is set with two pairs of values: last-modified/if-modified-since and ETag/ if-none-match Last-modified/If Modified – Since:

1) The browser sends the request for the first time and asks the server to return the last-modified value of the requested resource in the Response header. The browser will save the time;

2) Put if-modified-since in the request header the next time the browser requests it. A comparison is made between the modification time sent by the browser and the wh modification time of the server. If the modification time is consistent, the code resource is not changed, and the server returns a response with an empty body, allowing the browser to read the resource in the cache, thus reducing the request consumption.

Disadvantages:

1. As can be seen from the figure above, last-Modified saves the absolute time and is accurate to the second, so if the resource is Modified multiple times within 1 second, it will not be recognized.

2, for the file only changed the modification time, the content remains the same, this time will also make the cache invalid, in fact, this time we do not want the client to request again;

3, some servers can not accurately get the last modification time of the file; ETag/If-None-Match:

1) The first time the browser sends a request for the value of the ETag, the next time it sends the request header with if-none-match (the saved value of the ETag);

2) The ETag value sent is compared with the value of the ETag regenerated by the server. If the same value indicates that the resource has not changed, the server returns a response with an empty body, allowing the browser to read the resource from the cache, thus reducing the request consumption.

ETag works in much the same way as Last-Modified. However, ETag uses a collision-proof hash function (I don’t know what that is) for the resource content, using the hash value of the recently modified timestamp. ETag solves the problem of last-Modified.

Cons: ETag is a solution, but not perfect. ETag requires a read/write operation for every server generation (since it generates a hash), whereas Last-Modified only requires a read operation, which is more expensive.

Last-modified and ETag can also be configured at the same time. The server validates the ETag first. If the ETag is consistent, the server will continue to compare last-Modified, and finally decide whether to return 304.

ETag is higher for accuracy and slightly lower for performance (because of the hash generation)

The negotiated Cache is affected by the strong Cache. The negotiated Cache determines whether the Cache is cached only when the strong Cache expires and cache-control is not a no-store

2 Cache-controlWhat are the fields

Cache-control A generic header field used to specify directives to implement caching in HTTP requests and responses. Cache directives are one-way, which means that directives set in the request are not necessarily included in the response

grammar

Instructions are case insensitive and have optional arguments, which can be token or quoted string syntax. Multiple instructions are separated by commas

Cache request directive A standard cache-control directive that clients can use in HTTP requests.

Cache response instruction

Standard cache-control instructions that the server can use in response.  Extend the cache-control instruction

The extended cache directive is not part of the core HTTP cache standard document. Please check compatibility before using it.Cache-control: immutable / stale-while-revalidate=<seconds> / stale-if-error=<seconds> MDN,

H5 data storage mode (Cookie, localStorage, sessionStorage)

A Cookie is a request header that contains HTTP cookies previously placed by the server through the set-cookie header and stored to the client.

This header may be removed entirely, for example by disabling cookies in the browser’s privacy Settings;nameThe field is the name of a cookie.

The value field is the value of a cookie.

The domain field is the domain name from which this cookie can be accessed.

For a non-top-level domain name, such as a second-level domain name or a third-level domain name, the domain of the cookie can only be the top-level domain name or the second-level domain name or the third-level domain name itself. Cookies of other second-level domain names cannot be set. Otherwise, the cookie cannot generate top-level domain names. The domain name cannot be set to level 2 or level 3. Otherwise, cookies cannot be generated.

A second-level domain name can read cookies of a top-level domain name or its own domain, but cannot read cookies of other second-level domain names. Therefore, to share cookies among multiple secondary domain names, you need to set the domain to the top-level domain, so that all secondary domain names or the value of this cookie. A top-level domain can only obtain the cookie of a top-level domain. Other domains whose domains are set to second-level cannot be obtained.

The path field is the page path from which this cookie can be accessed. For example, if domain is abc.com and path is /test, only pages under /test can read the cookie.

The Expires/max-age field specifies the timeout period for this cookie. If the value is set to a time, the cookie becomes invalid when the time is reached. If this parameter is not set, the default value is Session, which means that the cookie will expire with the Session. This cookie expires when the browser closes (not the browser TAB, but the entire browser).

Size field The Size of this cookie.

The HTTPonly property of the HTTP field cookie. If this property is true, the cookie is only contained in the HTTP request header and cannot be accessed through document.cookie.

The Secure field sets whether this cookie can only be passed over HTTPS