What is cache?
Caching reduces the number of times for the browser to request resources. After the first resource request is complete, the browser stores some static resources on the local disk according to the corresponding caching mechanism. In this way, the browser directly reads the files from the local cache and does not need to send requests again. In this way, network latency is reduced, page response speed is accelerated, and user experience is enhanced. Reduce network bandwidth consumption; Reduces the strain on the server.
(This article focuses on the mind map)
What are the identifiers of the browser cache?
In Chrome, for example, open the developer tools, hit the Network TAB, and select All. This will show the loading status of all the static resources we requested.
A request with a non-zero size does not use caching. The size of the memory cache and disk cache indicates that the browser does not send requests to the server, but reads the local cache resource file directly.
What is a memory cache? What is a Disk cache? What’s the difference?
1, the Memory Cache
The memory cache is a special type of cache, which is not affected by max-age, no-cache and other configurations. Even if we do not set the cache, if the current memory space is sufficient, some resources will still be cached. However, this cache is temporary, and once the browser is closed, the amount of memory used for the cache is freed. If you really don’t want to use caching, you can set no-store so that even in-memory caching doesn’t work.
Memory caching, while efficient, is limited by the size of the computer’s memory, so we don’t have a lot of memory to use, which requires a hard disk to store a lot of the cache.
2, Disk Cache
A Disk Cache is a Cache stored on a hard Disk. The advantage over memory caching is longevity.
It determines whether the resource needs to be re-requested based on the field type set in the HTTP Header.
If the current memory usage is high, the requested resources are likely to be cached in the disk cache.
4. Cache process analysis
After the first request, the browser will get the result of the request and the cache id. Then, the browser will determine the cache processing method based on the response header returned by the first request, which is strong cache and negotiated cache respectively.
Strong cache
Instead of sending a request to the server, resources are read directly from the Cache. Strong caching can be implemented by setting two HTTP headers: Expires and cache-Control.
We will only emphasize cache-control here. Expires is an older approach and has some limitations. Use cache-control when setting Cache policies in your business.
Cache-Control
When cache-control :max-age=300, it means that the strong Cache will be hit if the resource is reloaded within 5 minutes of the correct return time of the request, which is also recorded by the browser.
Cache-control can be set in either request headers or response headers, and can be used in combination.
No-cache: indicates the content of the client cache. Whether to use the cache requires negotiation cache. Does not use cache-control Cache Control for pre-validation, but uses the Etag or Last-Modified field to Control the Cache. The name is a bit ambiguous. It does not mean that the browser cannot cache, but the browser needs to verify that the resource file is still consistent with the server before using cached data.
No-store: no content is cached, neither mandatory cache nor negotiated cache (memory cache also invalidates)
Max-age: max-age= XXX Indicates that the cache will be invalid in XXX seconds
Generally, we set the cache-control value to “public, max-age= XXX”, which means that the Cache will be accessed again within XXX seconds and no request will be sent to the server.
Strong cache based on a certain time or a certain period of time, so will not response to the change of the file server resources, once the resource file has changed, so strong cache files will not be in the range of time change, thus causing the inconsistent file browser and server problem, so how to solve this problem? This is where we need to use a negotiated cache.
Negotiate the 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 can be implemented by setting two HTTP headers, last-Modified or ETag.
Last-modified is the time when the resource file was Last Modified. The server will return the Response Headers, and the browser will place the if-modified-since in the Request Header next time it sends a Request. If they are the same, the negotiation cache is matched.
The Etag is a unique identifier of the current resource file returned by the server in response to a request. The Etag is regenerated whenever the resource changes. When the browser sends a Request to the server next time it loads a resource, it will add the Etag value returned last time to if-none-match in the Request Header. The server only needs to compare the if-none-match value sent by the client with the Etag of the resource on the server. It is a good idea to determine whether the resource has been modified relative to the client.
As you can see from the image above, the minimum time returned by Last-Modified is seconds, so there may be inconsistencies between the server resource and the local resource. If the request time is within 1s of the resource change, ETag uses a unique identifier, which is a good way to solve this problem.
Best practices for browser caching
Frequently changing resources
Cache-Control: no-cache
For resources that change frequently, cache-control: no-cache is used to make the browser request the server each time, and then ETag or Last-Modified is used to verify that the resource is valid. This does not save the number of requests, but it can significantly reduce the size of the response data.
A resource that is not constantly changing
Cache-Control: max-age=31536000
Such resources are typically processed by setting their cache-control to a large max-age=31536000 (a year) so that subsequent browser requests for the same URL will hit the strong Cache. To solve the update problem, you need to add the hash to the file name and then change the hash to change the request path.
HTML files do not set a strong Cache, the current development of pages, most of the cases are single page application, once the HTML can not be successfully updated, that will be a disaster level of technical failure, so HTML should set cache-control to no-cache, each request to the server file comparison.
CSS, JS, images and other resources can be set up a long time strong cache. When changing a file, use the hash value so that if the file changes, the browser requests the new resource directly. If the file does not change, the browser does not request the new resource directly using the local cache.