The cache location
The browser determines the location of the resource cache based on its size
- The service Worker browser caches independent threads
- Memory Cache: indicates the Memory Cache
- Disk Cache: Hard drive Cache
- Push cache scrub (http2 push cache)
Open the web page, enter the address, find whether there is a match in the hard disk, use it, not send a network request
Plain refresh: TAB is not closed and can be read from memory, then hard disk
Forced refresh: the browser does not apply Cache. The server returns 200 if the request header is cache-control :no-cache, and Pragma:no-cache for compatibility with IE
Cache way
The browser has two caching modes: strong cache and negotiated cache. When the browser determines that the cache file is expired, it queries the source server for the validity of the resource.
Strong cache
Definition: A request sent by a user is directly obtained from the server cache without sending the request to the server or interacting with the server
Strong caching is controlled using the Expires or cache-Control fields in the HTTP return header to indicate how long a resource is cached.
1. Expires Indicates the entity header field of an HTTP request.
This field is the HTTP1.0 specification, and its value is a time string in the GMT format of an absolute time, such as Expires:Mon,18 Oct 2066 23:59:59 GMT. This time represents the expiration time of the resource. When a cache server receives a request containing an Expires header field, it returns a copy of the response if it is within the expiration date. If it is outside the expiration date, it sends a request to the source server for the latest resource. If the source server does not want to cache the resource, it is a good idea to set Expires to the same value as the header field Date.
One obvious disadvantage of this approach is that since the outage time is an absolute time, it can lead to cache clutter when the server and client times diverging significantly.
2. The cache-control: Cache-control: XXXX Cache-control: XXXX Cache-control: XXXX Cache-control: XXXX Cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control: XXXX cache-control Indicates that the validity period of the resource is 3600 seconds. Cache-control In addition to this field, there are several common Settings:
- No-cache: no local cache is used. Cache negotiation is required to verify with the server whether the returned response has been changed. If there is an ETag in the previous response, the request will be verified with the server. If the resource has not been changed, the re-download can be avoided.
- No-store: directly forbids the browser to cache data. Each time the user requests the resource, a request will be sent to the server, and the complete resource will be downloaded each time.
- Public: can be cached by all users, including end users and intermediate proxy servers such as CDN.
- Private: the device can be cached only by the browser of the terminal user and cannot be cached by a trunk cache server such as the CDN.
- Max-age: The maximum time (in seconds) in which the response obtained is allowed to be reused from the current request.
Strong cache objects CSS files, JS files, etc., we generally do not have strong cache processing for HTML files. Usage:
- Identify the path with a timestamp or version number.
For example,
<link href="css/index.css? Version = 1.1"/>
Copy the code- Hash value, the hash value added to the name of the resource, which is regenerated whenever the file is updated. Webpack can be configured.
The strong cache HTTP status code is 200, regardless of whether the cache is used
Negotiate the cache
The browser’s negotiated cache mechanism is triggered only if the strong cache fails
Definition: a request sent by a user to a server that determines whether to read a resource from the cache
Negotiation cache means that the server determines whether the cache resource is available. Therefore, the client and server communicate with each other through some kind of identifier, so that the server can determine whether the requested resource is cache accessible. This mainly involves the following two groups of header fields. If a last-Modified or Etag field is not included in the response header of the first request, the subsequent request will be included in the corresponding request field (if-Modified-since or if-none-match). If no last-Modified or Etag field is included in the response header of the first request, There will be no corresponding fields in the request header.
Last-modified ` / If Modified – Since the HTTP 1.0
When a browser requests a resource for the first time, the server returns a header with last-modified. Last-modified indicates the time when the resource was Last Modified, such as last-modify: Thu,31 Dec 2037 23:59:59 GMT
When the browser requests the resource again, the request header contains if-modify-since, which is the last-modified value of the entity header field returned by the cache. After receiving if-modify-since, the server compares the value with the last modification time of the resource saved on the server to check whether the resource matches the cache.
If the cache is hit, a response with status code 304 is returned, the resource content is not returned, and last-modify is not returned. If the cache is not hit, the server returns a new resource and last-Modified status code of 200. Upon receiving the response, the browser saves the resource and last-Modified value for the next cache negotiation.
ETag/If HTTP 1.1 – None – Match
Unlike last-modify/if-modify-since, Etag/ if-none-match returns a check code. ETag ensures that each resource is unique, and resource changes result in ETag changes **. The server determines whether the cache is hit based on the if-none-match value sent by the browser.
Unlike last-Modified, when the server returns a 304 Not Modified response, the response header returns the ETag because it has been regenerated, even though the ETag is unchanged.
Why Etag
You might think that using Last-Modified is enough to let the browser know if the local cached copy is new enough, so why Etag? Etag was introduced in HTTP1.1 to solve several last-Modified problems:
- Some files may change periodically, but their contents do not change (just change the modification time). At this point we do not want the client to think that the file has been modified and GET again;
- Some files are Modified very frequently, such as If they are Modified less than seconds (say N times in 1s), and if-modified-since the granularity that can be checked is s-level, and such changes cannot be determined (or the UNIX record MTIME is only accurate to seconds).
- Some servers do not know exactly when a file was last modified.
Last-modified and ETag can be used together. The server will verify the ETag first. If the ETag is consistent, the server will continue to compare last-Modified, and finally decide whether to return 304.
User behavior
The user refreshes the interface and never extracts locally cached files