Recently, I was working on a project and encountered a browser cache, so the page data was not updated. And when the page style is not updated. This is due to browser caching. So let’s summarize what we know about browser caching.
A good caching strategy can reduce the repeated loading of resources and improve the overall loading speed of web pages. For current vUE and React single-page applications, caching strategies must also be considered when performing performance optimization.
Benefits of caching
- Reduce redundant data transmission and save bandwidth.
- Reduce the request load on the server. Caching can reduce the number of requests sent to the server, especially for some of the most visited sites.
- Resources are read from the cache without sending a request to the server and waiting for a return, which speeds up client access.
Problems with caching
If the project is updated, but the browser reads the cached resource when the user accesses it, then the user cannot get the latest page, affecting the user’s usage.
Classification of cache
There are many types of Web caches, such as database caches, proxy server caches, CDN caches, and browser caches. The browser sends requests to the source server through a proxy server.
Browser cache refers to HTTP cache, which performs operations based on the CACHE identifier of HTTP packets.
HTTP cache mechanism
Response operations are performed based on the cache identifier of HTTP packets.
The HTTP status code
Before discussing the browser cache, let’s take a look at the HTTP Status code associated with the web page. Open the console and catch the request under Network. Note the Status and Size fields.
| status | size | explain |
|---|---|---|
| 200 | memory cache | The status code is gray. The resource that has been loaded before is read from the memory and the server is not requested. When the page is closed, the resource will be released from the memory. Scripts, fonts, and images are stored in memory |
| 200 | disk cache | The status code is gray, read from the disk has been loaded resources, do not request the server, the page closed will not be released, this part of the resources in the computer disk, only when the user manually clear the browser cache will be released |
| 200 | The numerical size | Download the latest resource from the server. The value is the size of the entire resource retrieved from the server |
| 304 | The numerical size | Access the server and find that the resources are not updated. Use local resources. The value is the size of the message communicated to the server, not the size of the resource itself. |
Principles of three-level caching in browsers
- Memory cache: fastest read
- Local cache: Fast read
- Network cache: Slowest read speed
Cache processes
- First look up memory, if memory exists, load from memory;
- If it is not found in the memory, obtain it from the hard disk. If it exists in the hard disk, load it from the hard disk.
- If it is not found in the hard disk, a network request is made, and the loaded resources are cached to the hard disk and memory.
Caching strategies
There are two common browser caching strategies:
- Strong cache
- Negotiate the cache
Strong cache: expires&cache-control
Forced caching means that after a user accesses a page for the first time, the browser stores the data in the cache and does not request the server again until the expiration date. Whether to use a forced cache depends on whether the resource expires, which is obtained from the server response header of the first request. If it is read from the cache within the expiration time, if it is beyond the expiration time, the negotiated cache is used.
The fields that Control the mandatory Cache are Expires and cache-control, where cache-control takes precedence over Expires.
The cache-control header
The cache-control header defined in HTTP/1.1 is used to distinguish between support for caching mechanisms, and is supported by both request and response headers. Caching policies are defined by the different values it provides.
When used in the request header, the optional values are:
| field | instructions |
|---|---|
| no-store | No cache: Nothing about client requests and server responses can be stored in the cache. The complete response is downloaded for each request initiated by the client. |
| no-cache | Cache but revalidate: the following header definition, this way, every time a request, will cache the request to the server (translator note: the request should be with a local cache related validation field), the server will verify the request described in the cache is outdated, if has not expired (note: the actual return 304), the cache to use the local cached copy. |
| private | Private: The response is dedicated to a single user and cannot be cached by a middleman. The response can only be applied to the browser’s private cache. |
| public | Responses can be cached by any middleman (intermediate proxy, CDN, etc.) |
| max-age | In expiration mechanisms, the most important instruction is “max-age=”, which indicates the maximum time a resource can be cached (kept fresh). |
| must-revalidate | Validation mode: this means that when a cache is considered to use an obsolete resource, its state must be verified first. Expired caches will not be used. |
Negotiation cache: last-modified & etag
Negotiation cache, literally, is negotiation, browser and server negotiation, so the browser has to talk to the server every time. On the first request to the server, the server returns the resource and a cache id for the resource, which is stored in the browser’s cache database. When requesting resources for the second time, the browser will first send the cache id to the server, and the server will determine whether the id matches. If the id does not match, it indicates that the resource has been updated, and the server will return the new data and the new cache ID to the browser. If the cache id matches, the resource has not been updated and a 304 status code is returned, the browser reads the data from the local cache server.
The fields related to the negotiated cache are last-modified/if-modified-since and Etag/ if-none-match.
Etag
As a strong validator for the cache, If the resource request has an ETag in its response header, the client can validate the cache with an if-none-match header in subsequent requests.
Last-Modified
Last-modified is a weak validator, weak because it is accurate to only one second. If the response header contains this information, the client can validate the cache with if-modified-since on subsequent requests.
Than the response
Vary HTTP response headers determine how to decide whether to request a new resource or use a cached file for subsequent headers.
When the cache server receives a request, the cached response can only be used if the current request and the original (cached) request header match the Vary in the cached response header.
Reference links:
Blog.csdn.net/feiyu_may/a…
Developer.mozilla.org/zh-CN/docs/…