This is the third day of my participation in Gwen Challenge
π(a) Overview of browser cache
Front-end performance optimization has always been an old topic, among many methods of performance optimization, caching can be said to be a simple and efficient way of performance optimization.
π Where can browser caching give us substantial performance improvements?
π£ We know that there are roughly 5 steps from the time we enter the URL to the time the page loads
- DNS Domain name Resolution
- Establishing a TCP Connection
- HTTP request Throwing
- The server processes the request and the HTTP response returns
- The browser takes the response data, parses the response, and displays the parsed results to the user
Browser caching helps us optimize performance in steps 3 and 5. Using the browser storage mechanism, part of the data is saved to the client, which reduces the server request, reduces the server pressure, and improves the efficiency.
π’π’ A good caching strategy can shorten the distance of web page request resources, reduce latency, and because cached files can be reused, it can also reduce bandwidth and reduce network load π.
π(2) Specific use of browser cache
For my kind of chicken, the browser cache mechanism is understood as HTTP cache π₯΄, but a review of the data found that browser cache can be divided into four types, and they are ranked according to the priority of resource request as follows π³ :
- Memory Cache
- Service Worker Cache
- HTTP Cache
- Push Cache
Let’s take a look, Hurrah
1, π Cache Memory
A Memory Cache is a Cache in Memory that contains resources captured in the current page, such as styles, scripts, and images that have been downloaded on the page. It is the fastest Cache in terms of efficiency.
Can we use the Memory Cache without limit? The answer is no, because our computer memory is very limited. Usually Base64 images or smaller JS files are stored in Memory Cache, and larger files are stored on disk, such as this image:
The files in the figure all use data from the cache
2γ π£Service Worker Cache
A Service Worker is a separate thread that runs behind the browser and is typically used for caching. This is the introduction of it on the Internet. Later, IT is found that the transfer protocol must be HTTPS when using Service Worker. Since request interception is involved in Service workers, the HTTPS protocol must be used for security. It can help us to achieve offline cache, message push, network proxy and other functions.
The life cycle of a Service Worker includes three stages: Install, Active, and working. Once the Service Worker is installed, it will always exist and will only switch between active and working unless we actively terminate it. This is an important prerequisite that it can be used for offline storage.
π’π’ has found a good Service Worker practice article for those interested in using Service Worker and cacheStorage caching and offline development π
3, π€ HTTP Cache
HTTP caching is one of the most familiar caching mechanisms in our daily development, and it is also the most important and representative caching strategy. HTTP caching has a variety of rules, which can be divided into strong caching and negotiated caching, depending on whether a request needs to be redirected to the server.
Force caching does not need to interact with the server if it is in effect, whereas contrast caching does need to interact with the server whether it is in effect or not. Two types of cache rules can exist at the same time, and the force cache has a higher priority than the comparison cache. That is, when the force cache rule is executed, if the cache takes effect, the cache is directly used and the comparison cache rule is not executed.
π (1) Strong cache
Can be interpreted as a cache policy that does not require validation, forcing caching. For strong caching, there are two fields in the response header, Expires/ cache-Control, to indicate the rule. Expires Expires is used to set the expiration time, after which the resource Expires. One problem, however, is that since this time is represented by a timestamp, there may be differences between the client and the server, which can cause a cache life cycle error. Cache-control was added in HTTP/1.1, and cache-control takes precedence when both exist. Cache-control Cache-control has several values:
π1. private: the response can be cached by the client, indicating that the response can only be cached by a single user (operating system user or browser user). The response is non-shared and cannot be cached by the proxy server.
π2. public: both client and proxy servers can be cached
π3. max-age= XXX: The cached content will be invalid in XXX seconds
π4. no-cache: A comparative cache is required to validate cached data
π5. No-store: The cache is disabled and data is obtained from the server again for each request
π6. s-maxage but only for shared caches
π (2) Negotiate cache
π cache policy under browser – server cooperation
If the cached resource expires, it does not mean that the content of the resource has changed. If it is the same as the resource on the server, there is no need to request it again. The client and server side verify that the cache is available for the currently requested resource through some kind of validation mechanism.
If the server indicates that the cache resource is Not Modified, the resource is redirected to the browser cache. In this case, the status code for the network request is 304. Returning 200 is equivalent to rerequesting the resource and replacing the old one.
Let’s look at the request headers last-modified/if-modified-since and Etag/ if-none-match;
I, π last-modified/If – modified – Since
Last-modified is a timestamp that indicates when the server-side resource was Last Modified. If we enable negotiated caching, it will return with Response Headers on the first request. After the first request, the browser records this time, and the next request is preceded by if-Modified-since, which is the previously recorded time. The server receives an if-modified-since request and compares it with the last modification time of the resource. If modified, return the latest resource, status code 200, if not modified, return 304;
π£π£ But there are drawbacks to using last-Modified because the browser records the time itself. π Since last-Modified is only accurate to the second, if we modify the file too fast (100ms), the browser will not record this time and the file will not be updated in real time. π or we edit the file but update last-Modified when we submit it again, resulting in a complete response from the server
So how to solve this problem? Etag appeared as a complement to last-Modified
II, π Etag
An Etag is a unique hash string generated by the server for each resource. This identity string is encoded based on the content of the file, and the corresponding Etag is different as long as the content of the file is different, and vice versa. Therefore, Etag can accurately sense changes in the file.
π£π£π£ Note: The actual use of ETag/ last-Modified must be consistent, load balancing and reverse proxy may be inconsistent. Calculating eTags also requires resources. If the changes are not too frequent, see if your requirements can be met with cache-control.
4, π₯£ Push Cache
Push cache is set for HTTP/2 standard push resources. Push caching is session-level, and when a session terminates, the cache is released. It will only be used if none of the above three caches are present. Push Cache is a new feature of HTTP2, and it will be a future trend.
- Push Cache is the last line of defense for caching. The browser will only ask for Push Cache if the Memory Cache, HTTP Cache, and Service Worker Cache all miss.
- Push Cache is a Cache that exists during the session and is released when the session terminates.
Different pages can share the same Push Cache as long as they share the same HTTP2 connection. Here’s a πΆπΆ portal
Refer to the link
www.cnblogs.com/vajoy/p/534… www.cnblogs.com/chenqf/p/63…