How does the browser cache resources?

Cache can be divided into service worker, memory cache, and Disk cache according to location

memory cache

As the name implies, resources are cached in memory. In fact, all requests are cached in memory. The memory cache features a short duration — it is invalid when the TAB is closed. The capacity is limited, and the cache will become invalid after the capacity is exceeded. Control is in the browser, the front and back ends have no way to interfere.

disk cache

Disk cache. It can also be called HTTP caching because its caching rules strictly follow the HTTP header specification. The control of disk cache is in the back-end. Disk cache can be classified into strong cache and negotiation cache.

Strong cache

Strong cache has two related fields:

Expires.

This is a response header whose value is an HTTP timestamp, indicating that after this time, the resource will expire.

For example, Expires: Wed, 21 Oct 2015 07:28:00 GMT

Note:

  1. If an invalid date is set, the resource has expired.
  2. If max-age or s-max-age is set in cache-control, Expires is ignored.

Cache-control:

This is a common message field in request and response that is cached by specifying directives. The directive is one-way, that is, if it is set in the request, it may not be set in the response.

Multiple instructions are separated by commas.

Request instructions are as follows:

Cache-control: max-age=<seconds> // cache-control: max-age=<seconds> No-cache // [cacheability] Does not cache the contents of any request or response cache-control: no-storeCopy the code

Response instructions are as follows:

Cache-control: must-revalidate cache-control: must-revalidate cache-control: must-revalidate cache-control: max-age=<seconds> No-cache cache-control: no-store // [cacheability] can be cached by any object (client, proxy server) Public // [cacheability] Can only be cached by a single user, not as a shared Cache (for example, a proxy server cannot Cache) cache-control: privateCopy the code

Negotiate the cache

Negotiated cache is a conditional request. If the condition is not met, the request is not cached.

Last-Modified 、If-Modified-Since 、If-Unmodified-Since

Last-modified is the response header that contains the time the server identified the resource to have been Modified. Accuracy is lower than Etag.

If-modified-since and if-unmodified-since use last-modified values in conditional requests.

  • For GET/HEAD requests, return 304 without body If the requested resource has not been Modified Since if-modified-since, or 200 otherwise.

  • For requests to POST, PUT, or other non-safe methods, If the resource has been modified Since if-unmodifiedsince, error 412 will be returned.

Etag, if-match, and if-none-match

Etags are response headers and version-specific identifiers for resources, making caching more efficient and saving bandwidth. Because the web server does not need to send a full response if the resource content does not change.

If-match and if-none-match are request headers, and the values are taken from the Etag.

When used with if-modified-since, if-none-match has a higher priority.

Two examples illustrate the use of ETAGS:

1, POST, PUT, DELETE, etc., return 412, avoid “air collision”

For example, when user A edits the wiki, the current document content response includes:

Etag: 33 a64df551425fcc55e4d42a148795d9f25f89d4 ""Copy the code

When the document is saved, the POST request puts the previous Etag into the if-match to check If the latest version is saved:

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Copy the code

If it does not match, it means the document has been edited by another person and a 412 error is thrown.

2. GET HEAD to check whether the client resources are available

If a user requests to access a given URL with an Etag and is notified that the resource is expired and unavailable, the client places the Etag in if-none-match:

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Copy the code

The server compares the value of if-none-match from the client to the Etag of the current resource. If it matches, the server returns a 304 status code with no content.

service worker

Memory cache cannot be controlled. Disk cache can only be determined by setting header information in the browser.

But with the Service worker’s API, we can control the cache, including data, static resources, and even intercepting network requests.

The cache operated by the service worker can be seen in application -> Cache Storage and is permanent unless the capacity is exceeded or manually cleared.