Summary of a.
- Browser caches are HTTP caches that cache data in the browser (that is, the client).
- The server determines the cache policy by setting the HTTP response header to cache resources to the local browser.
Ii. Work flow
HTTP caching always starts with the second request.
- The first time a resource is requested, the server returns the resource and adds a caching policy to the response header.
- On the second request, the browser determines the request parameters, hits the strong cache, and grabs data from the local cache. If yes, 304 is returned. Otherwise, the server will return a new resource.
Strong and negotiated caching
- Strong cache: No interaction with the server
- Negotiated cache: Interacts with the server to determine whether to use locally cached files.
Caching example
- No cache:
- Negotiation cache:
- Strong cache:
- When there is no cache, the status code is 200, the transmission size is 6.9MB, and the transmission time is 8.63s.
- After setting the negotiation cache, the status code is 304, the transfer size is 350B, and the time is 100ms. The negotiation cache sends a 304 request to determine whether to use the local cache. If the cache matches, the browser directly obtains the cached file from the local, and the 6.9MB file does not need to be transmitted over the network. So the response time is dramatically reduced.
- Set strong cache and transfer time to 0ms. Because you don’t need to go over the network, you go directly to the local cache, so the response time is 0.
Several response headers that control the cache policy
Strong cache
4.1 Expires
Expires is a field that HTTP/1.0 controls the web cache. Its value is the expiration time of the result cache that the server returns for the request. That is, when a request is sent again, if the client’s time is less than the Expires value, the cached result is used directly. By HTTP/1.1, Expires has been replaced by cache-control, because the idea behind Expires caching is to compare the client’s time with the time returned by the server. If the client and the server’s time are different for some reason (time zone; If either the client or the server has a time error, the forced cache will be invalidated
4.2 Cache-Control
In HTTP/1.1, cache-control is the most important rule, which is mainly used to Control web caching. Its main values are:
- Public: All content will be cached (both client and proxy can be cached)
- Private: All content can be cached only by the client. The default value of cache-control
- No-cache: indicates the contents of the client cache, but whether to use the cache is verified by the negotiated cache
- No-store: All content is not cached, that is, neither mandatory cache nor negotiated cache is used
- Max-age = XXX (XXX is numeric) : The cache contents will expire after XXX seconds
- Must-revalidate: indicates that the browser and cache server can use the local replica before the local replica expires. Once the local copy expires, the validity of the local copy must be verified on the source server.
Cache-control is a better option than Expires in cases where it is not possible to determine whether the client’s time is in sync with the server’s.
4.3 Pragma
Pragma is a header property defined in the HTTP/1.0 standard. The effect of the Pragma included in the request is defined in the cache-control header: No-cache is the same, but the HTTP response header does not explicitly define this property, so it is not a complete replacement for the cache-control header defined in HTTP/1.1. Pragma is generally defined for backward compatibility with HTTP/ 1.0-based clients.
Note: The priority of the above three response headers is Pragma>Cache-Control>Expires
Negotiate the cache
4.4 the ETag
An ETag value is a string whose content is usually a hash of data, each of which has a separate flag that changes whenever the file changes.
The server can return an ETag in its response, and the browser will carry it with it in subsequent requests to determine if the cache needs to be updated. If the ETag values are the same, indicating that the resource has Not changed, the server returns a 304 (Not Modified) response code, and the browser knows that the local cache is still available.
4.5 Last-Modified
The server can configure this response header to send the browser a time label for the Last time the data was Modified, for example: last-Modified :Wed, 24 Apr 2019 02:54:16 GMT
In this way, the browser knows the time when the data was last modified. In subsequent requests, the time on the server is compared with the time on the local server. If the time on the server is newer than the time on the local server, the data has been changed and the browser needs to download the data again.
Examples of five.
To disable caching:
- To disable caching, set the response header cache-control: no-store, max-age=0. When the browser receives the response header, it specifies a policy against caching, and the next time the resource is requested, it sends a 200 request directly.
- The cache-controll values in the Cache header are the same as those in the Cache header. The Cache Controll values in the Cache header are the same as those in the Cache header. The Cache Controll values in the Cache header are the same as those in the Cache header, but the Pragma:no-cache values are the same as those in the Cache header. To determine whether to use local caching.
- Strong cache, where the Pragma response header is killed, the browser can implement strong cache strategy, directly from memory cache.
The relationship between user operation behavior and cache
- Normal refresh: When F5 is pressed or the refresh button is clicked to refresh the page, the browser bypassed the local cache to send the request to the server, in which case the negotiated cache is valid
- Forced refresh: When pressing CTRL +F5 to refresh a page, the browser bypasses various caches (local and negotiated caches) and sends the server back the latest resource
- Enter or Redirect: All caches take effect when entering enter in the address bar or pressing the jump button