preface

Recently do a third party platform jump login requirements, by the requirements can be divergent to the corresponding knowledge: browser cache, single sign-on, etc.. Therefore, I also came up with a learning plan to adapt myself to, that is, to expand my learning based on the knowledge needed in the project requirements of the current work, and so on, to learn the knowledge related to the next demand. As for the depth of learning and how much knowledge points to expand, it is determined by the degree of freedom in this period of time.

The cache

Caching: This usually refers to the caching of static resource files. This is usually done automatically by the client and server according to some rules of negotiation. “We don’t write any code to handle this”. Only API interface data caching, is the front-end development itself to complete

1. Why do we need browser caching?

When we visit the same page, the request for resources and data is time-consuming. If we can cache some resources, then from the second visit, we can reduce the load time, improve user experience, and also reduce the pressure on the server.

2. Cache classification

Web cache can be roughly divided into database cache, server-side cache (proxy server cache, CDN cache), and browser cache. Browser caches include many things: HTTP caches (strong and negotiated caches), data caches (cookies, localstorage, indexDB…) And so on.

3. Cache location

If caching is enabled, the information retrieved from the server is stored in:

  • Virtual Memory: Memory Cache (usually used to refresh pages without closing them)
  • Physical memory (hard Disk) : Disk Cache (page closed and reopened)

In other words, the client/browser keeps the cache in memory and on hard disk. An in-memory cache, where information is released as soon as the page is closed; The cache in the hard disk, is persistent storage, the page is closed and, unless they use some means to clear, such as 360 clear browser cache.

Specific processing steps:

  • Open web page: read Memory Cache first, then Disk Cache.
  • If the page is closed and then open, the system checks whether there is a match in the disk cache. If there is no match, the system sends a network request.
  • Normal flush (F5) : The TAB is not closed, so the memory cache is available and is used before the disk cache
  • Forced refresh (Ctrl + F5) : The browser does not use the Cache and obtains the latest resources from the server. Therefore, all requests are sent with cache-control: no-cache in the header

4. Cache processing

If there is a strong cache, there is a strong cache. If there is a strong cache, there is a strong cache. If there is a strong cache, there is a strong cache. (And so on)

5. Advantages and disadvantages of caching

Advantages:

  • Reduces unnecessary data transmission and saves bandwidth
  • Reduce server load and improve site performance
  • Accelerated client loading web page speed
  • User experience friendly

Disadvantages:

  • If the resource changes but the client is not updated in time, users will be delayed in obtaining information, which is even worse if the older version has bugs.

HTTP cache

HTTP caching is divided into strong caching and negotiated caching.

Strong cache

1. The concept and process of strong caching

The overall process of strong cache (also called forced cache) is relatively simple, that is, after accessing the server for the first time and obtaining data, the request will not be repeated within the expiration time. At the heart of this process is how to know if the current time has exceeded the expiration date, which is obtained from the response header returned when the server is first accessed. Implemented through different response header fields in HTTP1.0 and HTTP1.1 versions.

The browser’s handling of strong caching is determined by the response header returned when the resource is first requested

  • Expires: cache expiration time, used to specify when a resource expires (HTTP/1.0)
  • Cache-Control: cache-control: max-age=2592000 Within 2592000 seconds (30 days) after the first access to the resource, send the request again to read the information in the cache (HTTP/1.1).
  • Cache-control takes precedence over Expires when both are present

Some properties of cache-control:

  • No-cache: the cache can be cached locally or on a proxy server. The cache can be used only after verification
  • No-store: disables the browser cache and can only be obtained from the server
  • Max-age: Sets the expiration time of a resource (same effect as expires)

In general, both Settings are used in projects

Whether the resource information is retrieved from the strong cache or retrieved from the server, the HTTP status code is dominated by 200.

Strong caching is not suitable for static pages. If the pages are cached and the server updates the product later, we access the cached data, so that we can’t see the latest content.

2. In strong caching mode, other resource information is cached, deployed, and updated

Question: The file is cached locally, but the resource file corresponding to the server is updated. How can we ensure that we get the latest content

  • Request resource files “such as CSS/JS/ images…” “To set the timestamp
  • Generate different resource names based on WebPack (eg: XXX.min.css). The name of the generated resource will change if the code is updated and repackaged.

First request:

<link href='index.css? 20220305143712'> <script src='asfe4356.js'>Copy the code

After a day the CSS/JS content has changed, send the request again, making sure the timestamp is different, so that the local strong cache is not used, but the latest resource is pulled from the server again.

<link href='index.css? 20220306143712'> <script src='rtlg57903gdbsv.js'>Copy the code

If the suffix is found to be different from that cached last time, pull the latest information again.

HTML files are never cached! Otherwise, server resources cannot be updated, and clients can obtain the latest information at any time.

In normal projects, in addition to static pages, for CSS/JS/ images are generally strong cache.

Negotiate the cache

1. The concept of negotiation cache

Negotiation cache (also called comparison cache) is a process in which the browser sends a request to the server with the cache identifier after the strong cache is invalid (or non-existent) (eg: HTML can be used for negotiation cache). The server decides whether to use the cache according to the cache identifier

  • Static pages can be processed using negotiated caching
  • For the rest of the resource files, we use strong cache + negotiated cache

2. Negotiate two groups of cached fields

  • Last-modified & if-modified-since: The former is used to record the time when the server resource file was Last updated and exists in the response header; The latter is when the next time the same resource is requested, the browser finds an “indeterminate” cache in its cache and writes the Last last-modified value to the if-Modified-since field in the request header. The server compares the if-modified-since value to the last-Modified field. If the value is equal, it indicates that it has not been Modified, and responds with 304, otherwise it responds with 200 status code and returns data.

  • Etag & if-none-match: the former will generate a different identifier (usually hash generated) whenever the server resource file changes. The latter is similar to if-modified-since for the previous set of fields. The server will also compare the two, returning 304 on a hit and 200 on a miss.

They can be used together and have a higher ETag priority.

Problem with page refresh:

  • F5 Refresh: Do not use strong cache, use negotiated cache
  • CTRL +F5: Use neither

Etag was introduced in HTTP1.1 to solve several last-Modified problems:

  • Some files may change periodically, but their contents do not change (only the modification time), and we do not want the client to think that the file has been modified and get again.
  • Some files are modified very frequently, such as in less than seconds (such as N changes in 1s), and if-modified-since the granularity that can be checked is in seconds, making such changes impossible to determine (or UNIX records MTIME can only be accurate to seconds).
  • Some servers do not know exactly when a file was last modified.

Summary of common points:

Both strong and negotiated caching are server-side Settings, performed automatically by the client browser without front-end coding, and both are for static resource files.

Data cache

Data caching is to cache data interfaces that do not need to be updated frequently. Data cache can not rely on the server and browser to automatically deal with it, it needs JS storage scheme and related operations to code.

1. Data caching requirements

There is no cached data locally/the cache fails and we pull the latest data from the server (similar to a strong cache); Local cache data is not expired, we directly read the cached data (reduce the frequency of interaction with the server, reduce the server pressure, can also improve the page rendering speed…)

  • Page does not refresh, we frequently operate some content, but the data does not need to get the latest in real time, you can do a cache; As soon as the page refreshes, get the data from the server again;
  • As long as the page is not closed, we read cached data “for infrequently updated data”;
  • Even if the page is closed and reopened, we can also read the data in the cache. “The data update frequency is lower, and we set the expiration period by ourselves.”
  • .

2. Data storage scheme on the client

  • (global) Variable store “vuex/redux” : the page is refreshed or closed and reopened without any data stored before (memory release problem)

  • Local storage: local storage scheme based on JS management (all important information is stored in plaintext, so it can be encrypted by MD5 instead of stored directly)

    • cookie

    • WebStorage: localStorage & sessionStorage

    • IndexedDB

    • Web SQL

    • Cache

    • Manifest offline storage

    • .

Information stored locally is stored as strings!

The local storage scheme based on JS management is stored in the physical memory of the computer, while the global variable storage is stored in the virtual memory.

3.cookie

Operation: Obtain and set through document.cookie

Features:

  • Have expiration date: Cookies need to set expiration time, beyond the time will be invalid (within the validity period, whether the page is refreshed or closed and then opened again, the stored information is in), and there are path restrictions!
  • Restricted by source and browser: Cookie information can only be accessed from the same source and cannot be obtained after changing the browser
  • The storage size is limited: a maximum of 4KB can be stored in the same source.
  • Unstable: Based on the security guard or browser’s own clear operation, the cookie will be eliminated; If you enable traceless browsing or privacy mode, you cannot store cookie information!
  • Compatibility: Cookie is compatible with older browsers.
  • There are bugs with the server: Cookies are not strictly local storage and there are a lot of bugs with the server. When the client sends a request to the server, it sends the local cookie information to the server based on the request by default. And if the server returns a set-cookie field in the response header, the browser will default to cookies on the client side. ! (So the more local cookies you store, the more stuff you send per request to the server, and the slower it is.)

4.localStorage

Operation:

Localstorage.setitem (key,value) localStorage.getitem (key) localStorage.removeItem(key) localstorage.clear () // Clear all...Copy the code

Features:

  • Persistent local storage: There is no expiration time, and the contents of the page closed store are still there, and will only be cleared manually (or by uninstalling the browser)
  • Restricted by source and Browser
  • The storage capacity is limited: a maximum of 5M content can be stored in the same source.
  • With stability: clear computer garbage or history records on its storage information has no impact, and traceless mode can also store information!
  • No connection to the server: There is no connection to the server unless you manually pass local storage information to the server.

Implement localStorage with a validity period

  1. When storing information, store one more key-value pair for time.
  2. When fetching later, use the current time-storage time to verify that the difference is within your specified validity period.

The code implementation of this will be encapsulated later.

5.sessionStorage

With localStorage only one difference: localStorage is persistent storage, page refresh or close, stored information is still in; SessionStorage is a sessionStorage, the page refresh information is still in, but once the page closed (session ended), the stored information will be released.

6. Encapsulate the data caching method of localStorage

* @param func * @param func * @param func * @param name localStorage key used to store information * @param limit Validity period (milliseconds) default one hour */ function cacheStorage(func, name, limit) { if (typeof func ! == 'function') throw new TypeError('func is not function'); if (typeof name ! == 'string') throw new TypeError('name is not string'); if (typeof limit ! == 'number' || isNaN(limit)) limit = 3600000; return new Promise(async (resolve, reject) => { let result = localStorage.getItem(name), now = +new Date(); if (result) { let { time, data } = JSON.parse(result); If (now-time < limit) {resolve(data); return; }} // cache invalid try {result = await func(); localStorage.setItem(name, JSON.stringify({ time: +new Date(), data: result })); resolve(result); } catch (err) { reject(err); }}); }Copy the code