This is the 16th day of my participation in the August More Text Challenge

In the process of performance optimization, browser cache is an essential part of optimization, and browser cache can play an immediate role in performance optimization

Knowledge of the browser cache is also a common question in the interview process. Knowing the browser cache makes for a better interview

Browser cache

Caching different types of work have different specific scenarios, in the database cache, Redis cache, CDN cache and browser cache, as the front-end needs to focus on browser cache

What is a browser cache?

HTTP caching (or Web caching) is an information technology used to temporarily store (cache) Web documents, such as HTML pages and images, to reduce server latency. The HTTP caching system keeps copies of documents that pass through it; Subsequent requests can be satisfied by the cache if certain conditions are met. HTTP caching systems can refer to either devices or computer programs.

Caches are useful for:

Avoid unnecessary data transfer, improve page loading and display speed, reduce the burden on the server: After the user opens the website, if the browser has not expired the relevant resources, it does not need to obtain the resources through the request again and directly uses the browser cache resources. In this process, HTTP requests can be saved, the arrival time of resources is increased, the time of resource parsing is accelerated, and the page is opened faster. As the number of requests decreases, the server can save a lot of HTTP traffic resources

Cache classification:

According to the slow invalidation policy, caches can be classified into two types: strong cache (local cache) and negotiated cache (weak cache)

Strong cache (local cache)

Strong caching means that after a browser requests resources for the first time, it sets Http headers to cache resources. Within the cache validity period, the browser does not need to request the server to load resources again and directly uses the local cache resources of the browser

The main concepts of strong caching: Expires and cache-control

Why are there two ways to set up a strong cache?

Expires.

Back in HTTP1.0, it was stipulated that HTTP Header Expires is a reality cache by setting the value to a timestamp. After the browser first visits the site, the server will send the Expires field in response to the HTTP Header, so when the browser needs to use the resource again, The current device time is first compared to the Expires time. If the current device time is earlier than Expires, the browser cache is used directly. If it is later, the request needs to be sent again

Set Expires:

Expires: Sat, 07 Aug 2021 07:38:29 GMT
Copy the code

Setting Expires tells the browser that any attempt to use the set Expires resource until 2021-08-07 07:38:29 will use the browser’s local cache directly

Expires: - 999.Copy the code

When set to negative, it tells the browser that the resource is cached, but is immediately invalidated and requires a negotiated cache

Expires defects:

  • The GMT time on the server and client may differ
  • If you change the local time, the client-side date may be inaccurate
  • Too complicated a string with too many Spaces and too few letters will result in invalid properties and invalid Settings

Cache-control:

Back in HTTP 1.1, HTTP used the cache-Control response header, which is more powerful and has a more flexible configuration than Expires:

Private: indicates that the private cache can be cached only by clients, not by the common cache proxy server, and cannot be shared among users

Public: indicates the shared cache, which can be cached by clients and proxy servers. For example, the CDN can be shared among multiple users

Max-age: indicates that the cache will expire after this value. Max-age: 100 Indicates that the cache will expire after 100 seconds

S-maxage: the value, in seconds, overrides max-age and has the same effect but only on the proxy server

No-cache: The resource is cached, but is immediately invalid, and a negotiated cache is required (a request is required to verify that the resource has expired)

No-store: All content is not cached

Must-revalidate: tells the browser that you must validate again to see if the message is out of date, and returns 304 instead of 200

A separate set

cache-control: max-age=31536000
Copy the code

Indicates that the cache time of the resource expires after 31536,000 seconds

Combination Settings: Multiple Settings can be set at the same time

cache-control: public, max-age=31536000
Copy the code

Indicates that the resource can be cached by clients and proxy servers, but the resource expires after 31536,000 seconds

Strong cache priority:

When both Expires and Cache-Control: max-age=100 are present, HTTP dictates that max-age takes precedence and overwrites Expires

Negotiated cache (weak cache)

Now you have a JS resource with a strong cache time set for it, but the JS resource has not been updated during the strong cache time. The browser will reload the resource even if the resource has not been modified. If the JS resource is updated during the strong cache time, the browser will not reload the latest resource and continue to use the old version of the JS resource. How to set strong cache times is a headache

Strong caching is good, but it has its drawbacks, and this is where negotiating caching comes in

Negotiation cache process: On the browser, if a request for a resource does not match the strong cache, the browser sends a request to the server to verify whether the negotiation cache is matched. If the negotiation cache is matched, the HTTP status returned by the response is 304.

The negotiated cache is implemented by setting up two pairs of good gay friends: last-Modified and if-Modified-since, ETag, and if-none-match

Last-modified, if-modified-since negotiation cache process:

  • When the browser requests a resource for the first time, the server adds a last-Modified field to the response header that returns the resource. This field indicates the Last time the resource was Modified on the server
Last-Modified:  Sat, 07 Aug 2021 07:38:29 GMT
Copy the code
  • The browser receives the response and records the last-modified response header with a value of T
  • When the browser requests the resource again from the server, the request header is appended with the if-Modified-since header. This if-Modified-since value is the last-Modified response header returned by the back end when the resource was Last requested
  • After receiving the request again, the server determines whether the related resource has changed after T according to the value T of if-Modified-since in the request header. If there is no change, 304 Not Modified is returned and the resource content is Not returned. The browser uses the resource cache value. If there is a change, the resource content is returned normally and the last-Modified response header content is updated

The ETag and if-none-match negotiation cache processes are consistent with last-Modified and if-Modified-since. The difference is that ETag and last-Modified are generated in different ways

Last-modified is generated based on the Last modification time of the resource

Etags are generated based on the content of the resource

Negotiate cache priorities:

Etag has a higher priority than last-Modified, and if a combination appears in the request header, the browser uses Etag first

conclusion

Strong and negotiated cache priorities:

Priority: Cache-Control > Expires > ETag > last-Modified

Usage Scenarios:

The forced cache has the highest priority, and the browser does not send requests for resource changes within the cache validity period. Therefore, the forced cache applies to large resource files that are difficult to be modified, such as third-party CSS, JS files, and image resources

Negotiation cache has high flexibility and is suitable for data cache. Based on the above knowledge, Etag is the most flexible and reliable comparison method. For data caching, memory can be considered as the fastest loading speed and data size is small