Without further ado, first a structure diagram:

The caching technology involved in the front-end is mainly shown in the figure, isn’t it very clear and simple? Among them, about LocalStorage (LocalStorage, SessionStorage) is used in specific business logic. This paper mainly introduces the cache configuration strategy under the front-end engineering system (that is, the browser cache strategy for static resources such as JS, CSS and images).

HTTP Cache Policy

The browser’s caching of static resources is essentially an HTTP caching policy. According to whether to send requests to the server, HTTP caching policies can be divided into mandatory caching and negotiated caching.

1. Enforce cache policies

The browser does not make requests, but decides whether to use the local cache or request new resources based on the expiration date. Such a policy is called a forced cache policy.

Expires and cache-Control are important response headers for enforcing caching policies.

(1) Expires

Expires is a feature added to HTTP1.0 by specifying a specific point in time when a cached resource will expire, meaning that if the resource is requested again before that point, the browser will simply retrieve it from the cache without making a request again. For example :(request from nuggets site analytics. Js)

expires: Wed, 19 Sep 2018 10:36:19 GMT
Copy the code

But Expires has a serious problem: It’s based on the server’s time, but the browser is comparing it to the local time, so there’s an error (for example, if the server is in China and you’re in the U.S. using a browser), which is obviously not justified.

(2) the cache-control

To address the Expires problem, HTTP1.1 adds a new response header: cache-control. Cache-control is used in the following ways:

No-cache: the browser sends a request to the server. The server checks whether the resource has changed. If the resource has not changed, the browser cache (that is, the negotiated cache policy) can be used.

No-store: indicates that the browser sends a request to the server to download the resource again regardless of whether the resource changes. It is a true prohibition of caching.

Max-age: specifies the maximum time, in seconds, that this resource can be cached from the time of request. For example, if the request max-age of analytics. Js is 7200, the browser will use the local cache if it encounters another request for this resource within 2 hours.

Max-age specifies a period of time, which is equivalent to an absolute value, so it is not affected by the time between the browser and the server. It has a higher priority than Expires.

2. Negotiate cache policies

The browser makes a new request and the server compares the resource to the local cache or the new resource. This strategy is called the negotiated cache policy. (As the name implies, the browser and the server negotiate to resolve this matter)

The criteria for enabling a negotiated Cache policy are: Cache-control is set to no-cache or max-age and Expires are expired.

The Etag and If – none – match

Etag is a unique identifier assigned by the server to a resource and is returned to the browser as a response header. When using the negotiation cache policy, the browser sends the Etag value to the server via if-none-match. The server receives the request and compares whether the Etag value of the requested resource has changed. If it has Not changed, the server returns 304 Not Modified to tell the browser that the file has Not changed. So the browser goes back to the cache; If the resource changes, the server returns the latest resource and resets its Etag value.

Finally, here is a front-end cache strategy flow chart :(I have been drawing for a long time, and I am satisfied with it.

From memory cache; from disk cache; from memory cache;

From memory cache: To fetch from memory, close the browser. Script files, fonts, and images are stored in memory.

From disk cache: The request can be fetched from the disk even after the browser is closed. Non-script files, such as the CSS, are stored in memory