As one of the most effective ways to optimize front-end performance, caching is relatively familiar to front-end developers as HTTP caching.
What is HTTP caching?
HTTP caching refers to the fact that when a client requests a resource from a server, it reaches the browser cache first, and if the browser cache has a copy of the resource to request, it obtains the resource directly from the browser cache rather than from the target server.
Although HTTP caching is not required, it is often necessary to reuse cached resources. However, common HTTP caches store only GET responses, not other types of responses.
Why use HTTP caching?
- Reduce redundant data transmission
- Reduce server stress and improve site performance
- Speed up the client to load web pages and resources
Which resources can be cached?
This typically includes HTML pages and other static resources (JS, IMG, CSS, etc.)
HTTP cache classification
- Strong cache
- Expires (HTTP 1.0)
- In the Response Headers
- Control cache expiration time
- Has been replaced by cache-control
- The value is the absolute time on the server
- Cache-control (HTTP 1.1)
- In the Response Headers
- Controls the logic of forced caching
- Example: cache-control: max-age=31536000 (in seconds)
- value
- Max-age Cache expiration time (relative time)
- No-cache Does not require local mandatory cache. Negotiation cache is required and a request is sent to the server to confirm whether the cache is used.
- No-store does not enforce local caching, nor does it require server-side caching. Data is rerequested each time.
- Private can only be cached by end users, such as computers, browsers, and mobile phones
- Public is allowed to be cached by any middleman (such as intermediate proxy, CDN, etc.)
- Negotiation cache (contrast cache)
- Server-side caching policy (server determines whether resources can use cached content)
- The server determines whether the cache resource is the same as the server resource (304 is always returned, 200 and the latest resource is returned otherwise)
- In Response Headers, there are two
- Last-modified Time of the last-modified resource (accurate to the second level only)
- Unique identification of Etag resources (preferred)
5. Cache execution process
When loading a resource, the browser determines whether the strong cache is matched based on the header (Expires and Cahe-Control) information of the local cache resource. If the strong cache is matched, the browser directly uses the cached resource without sending a request to the server. When the strong cache is not hit, the browser sends a request to the server, which determines whether the cache is hit based on the information in the header (if-modified-since and if-none-match). If it hits, 304 is returned, telling the browser that the resource is not updated and that the local cache is available.
6. Refresh operation mode and its impact on cache
- Three refresh operations
- Normal operation: enter URL in address bar, jump link, forward and backward, etc
- Manual Refresh: F5, click refresh button, right click menu refresh
- Force refresh: CTRL + F5 (Mac: Shift + Command + R)
- Different refresh operations, different cache policies
- Normal operation: Force cache valid, negotiate cache valid
- Manual refresh: The forced cache is invalid, but the negotiated cache is valid
- Force refresh: Force cache invalidation, negotiation cache invalidation