HTTP caching: An information technology used to temporarily store (cache) Web documents (such as HTML pages, JS, and images) to reduce server latency.
The HTTP caching system saves copies of documents that pass through the system, and if certain conditions are met, the content can be cached to return request results. An HTTP caching system can be a device or a computer program.
Using caching is one way to speed up web pages and is almost always our first choice for performance optimization. A good caching strategy can shorten the distance of web page request resources, reduce latency, and reduce bandwidth and network load because cached files can be reused.
Too often, people tend to think of browser caching simply as “HTTP caching.” But in fact, HTTP caching is a type of browser cache.
The browser resource cache can be divided into two main categories: memory cache and disk cache
When a web page is first accessed, the resource file is cached in memory and a copy is kept on the local disk.
When the user refreshes the page, if the cached resources do not expire, the user can directly read and load the data in the memory. After the user closes the page, the current page cached resources in the memory will be cleared. So the in-memory cache is the first one that the browser tries to hit. It is the most responsive cache in terms of efficiency, but it is also “short-lived”, being emptied after the page is closed.
When the user accesses the page again, if the cache of the resource file has not expired, the data can be loaded from the local disk and cached again into memory.
Here is a table of cache behavior transformations for several typical refresh operations:
HTTP cache details
Strong cache
Strong caching is controlled using the Expires and cache-Control fields in the HTTP header. If yes, resources are directly obtained from the cache without communication with the server. The returned HTTP status code is 200. The following figure
Expires: Controls when a cache expires with an absolute timestamp.
Max-age: to achieve the same goal over a relative length of time. Max-age can be a complement/replacement for expires capabilities. In today’s front-end practices, we generally prefer max-age. Max-age takes precedence over Expires. When both cache-control and Expires are present, cache-Control takes precedence.
No-cache: Bypasses the browser and sends a request directly to the server to confirm whether the resource is expired or not.
No-store: directly sends requests to the server without using any cache policy.
Public: If the resource is set to public, it can be cached by both the browser and the proxy server.
Private: Resources can only be cached by the browser. Private is also the default.
Negotiate the cache
In the negotiation cache mechanism, the browser needs to ask the server for cache information to determine whether to resend the request or obtain cache resources from the local server.
If the server prompts that the cache resource is Not Modified, the resource is redirected to the browser cache with the corresponding status code 304, as shown below:
* * last-modified: ** is a timestamp that returns last-Modified when negotiated caching is enabled for the first time. Each subsequent request carries the last-modified value returned as if-Modified-since. When the server receives this timestamp, it returns the last-modified value as if-Modified-since. If the timestamp changes, the new last-Modified value is returned; otherwise, 304 is returned, and Response Headers does not add the last-Modified field.
Last-modified has two common drawbacks:
1, edit the file, but the file content is not changed, the server will still determine the editing time. A re-request would not have been required.
2. The file content is modified too fast. Since last-modified-since can only detect the time difference in seconds, it cannot detect the change in milliseconds. Originally should request again, did not request again.
Etag: A unique identifying string generated by the server for each resource. Etags are encoded based on the contents of the files, and they correspond to different ETags whenever the contents of the files differ.
Etag is also the first request, and Response Headers gets an initial identifier string in the Response header. In the next request, the Etag in the request header is provided to the server as if-none-match, similar to last-Modified. The downside is that it requires extra overhead on the server, which can affect performance on the server side.
Note: Etag does not replace Last-Modified, but can only be used as a complement to last-Modified. Etag detects file changes more accurately than last-Modified and has a higher priority. When last-Modified and Etag exist together, Etag prevails.