An overview,

Front-end caching, also known as HTTP caching, is an important aspect of front-end performance optimization. Front-end local storage is not the same as caching, but it can be confusing for beginners. This paper records their concepts and characteristics in detail

HTTP caching

HTTP cache, you can learn from the cache location, get the cache mode

The cache location

  • service worker
  • Memory Cache
  • Disk Cache
  • Push Cache

Search cache priorities are matched from top to bottom, and network resources are requested only if none is found

service worker

A middleman role between the server and the browser. If a service worker is registered in the website, it can intercept all the requests of the current website and make judgment (corresponding judgment program needs to be written). If it needs to send requests to the server, it can transfer them to the server. If you can use the cache directly, you just return it to the cache and don’t transfer it to the server. Thus greatly enhancing the browsing experience.

  • To use the Service Worker, the transport protocol must be HTTPS
  • You can give the developer control over the content and version of the managed cache
  • The Service worker runs in the worker context –> cannot access the DOM
  • It is designed to be fully asynchronous, and synchronization apis such as XHR and localStorage are not available in service workers
  • Its life cycle is page-independent (it can exit if the associated page is not closed, or start if there is no associated page)

Memory Cache

The cache in memory mainly contains the resources that have been captured in the current page, such as the styles, scripts and images that have been downloaded on the page. It is definitely faster to read data from memory than from disk. Although memory cache reads data efficiently, it has a short cache duration and will be released as the process is released. Once we close the Tab page, the cache in memory is freed.

Memory caching of cached resources does not care about the value of the HTTP Cache header cache-Control that returns the resource, and the matching of resources is not only for URL matching, but also for content-Type, CORS and other characteristics.

Disk Cache

A Disk Cache is a Cache stored on Disk. It is slower than a memory Cache in terms of access efficiency, but its advantages lie in storage capacity and storage duration. Generally speaking, the view is that large JS and CSS files will be directly thrown into the disk, and conversely into the memory; When the memory usage is high, files are preferentially transferred to disks. In actual Cache use, Disk Cache coverage is basically the largest

Push Cache

Push Cache is HTTP/2 and is used when all three caches fail. It only exists in the Session, is released once the Session ends, has a short cache time (about 5 minutes in Chrome), and does not strictly implement the cache instructions in the HTTP header.

Obtaining cache mode

After the browser sends the request to the server for the first time and gets the request result, it stores the request result and the cache identifier in the browser cache. The browser’s processing of the cache is determined by the response header returned during the first request for the resource

Strong cache

If the conditions of obtaining cache are met, resources are directly read from the cache without sending a request to the server

Expires

Expires is a response header returned by the server that tells the browser to retrieve data directly from the cache before the expiration date, without having to request it again. However, server time and client time can be inconsistent, which will also cause errors in Cache hits, so cache-control was replaced in HTTP1.1 and is now generally used for compatibility

Cache-Control

Cache-control has many attributes. Different attributes have different meanings. Multiple commands can be used flexibly.

Negotiate the cache

Negotiated cache is a process in which the browser sends a request to the server with the cache identifier after the cache is invalid, and the server decides whether to use the cache based on the cache identifier. Negotiated cache can be implemented by setting two HTTP headers: Last-Modified and ETag.

Negotiation caches require comparison to determine whether caches can be used. The first time the browser requests data, the server responds with the cache id along with the data to the client, which backs it up to the cache. When requested again, the client sends the cached identity to the server, which determines based on this identity. If not, the 304 status code is returned and the browser can use the cached data directly

Last-Modified

When the server responds to the request, it tells the browser when the resource was last modified.

If-modified-since: The request header contains this field when the browser requests the server again, followed by the last modification time obtained in the cache. The server receives the request with if-modified-since, and compares it with the last Modified time of the requested resource. If the request is consistent, 304 and the response header are returned. The browser only needs to retrieve the information from the cache. Whether a file has been modified since a certain point in time

  1. If it is, the server returns 200 OK in response to the resource content
  2. If Not Modified: the server returns 304 Not Modified
ETag

This field tells the browser the unique identity of the current resource generated by the server when the server responds to a request (the generation rules are determined by the server)

If-none-match: If the browser requests the server again, the header of the request packet contains this field, and the following value is the identifier obtained from the cache. After receiving the secondary packet, the server compares if-none-match with the unique identifier of the requested resource.

  1. If no, the resource has been modified. The server returns 200 OK in response to the resource content
  2. If yes, the resource has Not been Modified and 304 Not Modified is returned to the server

contrast

  • Etag is more accurate than Last-Modified

  • In terms of performance, Etag is worse than Last-Modified, which only takes time to record, whereas Etag requires the server to compute a hash value through an algorithm.

  • Etag/if-none-match has a higher priority than last-modified/if-modified-since. If both Etag/if-none-match exist, only Etag/if-none-match takes effect.

The impact of user behavior on caching

  • Address bar Enter: Both strong cache and negotiated cache are valid
  • Page link skipping: Both strong cache and negotiated cache are valid
  • New window: Both strong cache and negotiated cache are valid
  • F5 Refresh: Strong cache is invalid, negotiated cache is valid
  • Ctrl+F5 Refresh: Both strong cache and negotiated cache are invalid

Cache advantages

  • Redundant data transmission is reduced and broadband traffic is saved
  • Reduce the server burden, greatly improve the performance of the site
  • Accelerated client loading web page speed

Local storage

Front-end localStorage cookie, localStorage, sessionStorage, IndexedDB, etc., but also commonly used cookie, localStorage, sessionStorage. So you can directly analyze the characteristics of these three types of local storage, from storage size, data availability, scope, communication to compare

Comparison of common local storage

Storage size

  • Cookie: Generally less than 4K (because cookies are carried with each HTTP request, cookies are only suitable for storing very small data, such as session identifiers)
  • SessionStorage, localStorage: generally 5M or larger, depending on the browser

Data validity

  • Cookie: Generally generated by the server, you can set the expiration time. If the time is not set, close the browser and the cookie will be invalid. If the time is set, the cookie will be stored in the hard disk until it expires
  • SessionStorage: valid only before the current browser window closes, the closed page or browser is cleared
  • LocalStorage: permanently available, saved even when the window or browser is closed, unless permanently removed manually, and therefore used as persistent data

scope

  • Cookie: Shared across all origin Windows
  • SessionStorage: shared within the same browser window (different browsers, same page is not shared)
  • LocalStorage: Shared in all origin Windows

communication

  • Ccokie: Automatically carried in same-origin HTTP requests, even if not required, so cookies are passed back and forth between the browser and the server; Using cookies to store too much data can cause performance problems
  • SessionStorage and localStorage: stored only in the client (browser) and do not communicate with the server. Data is not automatically sent to the server, only stored locally

conclusion

Cookie and Web Storage, including other local Storage, have their own advantages and disadvantages, such as cookie capacity is too small, there are security defects and certain performance defects, Web Storage was born for local Storage, so it cannot participate in communication, and such as IndexDB, compatibility is not very good, So we need to be flexible in choosing the right scenario

The end of the

❤️❤️❤️ 1. Please give me a thumbs-up when you see here. Your thumbs-up is the motivation for my creation. 2. My blog, thanks to Star.