HTTP cache

HTTP caching is used by clients to store static files (images, CSS, JS, etc.) that do not change often. It is divided into mandatory cache and negotiated cache.

  • HTTP caching procedure

    Request => Match strong cache => match negotiation cache => obtain resource

  • HTTP Cache Flow Chart

1. Force cache

  • Caching rules

    When a browser requests a resource, it obtains the header information of the resource cache to determine whether the strong cache (cache-control and Expires information) is matched. If the header information is directly obtained from the cache, the request does not communicate with the server.

  • Caching scheme

    Expires: The expiration time in the response header. If the browser reloads the resource within this expiration time, the strong cache will be hit.

    Cache-control: when max-age=300, it means that the strong Cache will be hit if the resource is reloaded within 5 minutes of the correct return time of the request, which is also recorded by the browser.

    Cache-control and Expires both specify the expiration date of the current resource and Control whether the browser Cache data directly from the browser or re-request data to the server. It’s just that cache-Control has more options, is more elaborate, and takes precedence over Expires when set at the same time
    Cache-control In addition to this field, there are several common Settings:

    The value can be public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, or max-age.

    • Public indicates that the response can be cached by any cache.

    • Private indicates that all or part of a response message from a single user cannot be processed by the shared cache. This allows the server to describe only a partial response message from a user that is not valid for requests from other users.

    • No-cache indicates that request or response messages cannot be cached

    • No-store is used to prevent important information from being inadvertently published. Sending in the request message will result in neither the request nor the response message using caching.

    • Max-age indicates that a client can receive a response with a lifetime not longer than the specified time in seconds.

    • Min-fresh indicates that the client can receive a response with a response time less than the current time plus the specified time.

    • Max-stale indicates that the client can receive response messages beyond the timeout period. If you specify a value for a max-stale message, the client can receive a response message beyond the specified value for the timeout period.

2. Negotiate cache

  • Caching rules

    If the strong cache is not hit, the browser sends a request to the server with the header field information returned for the first time (last-modifued/if-Modified-since and Etag/ if-none-match). The server compares the result based on the header information to determine whether the negotiation cache matches. If a match is made, the server returns a new response header to update the corresponding header in the cache, but does not return the resource content, which tells the browser that it can be retrieved directly from the cache; Otherwise, the latest resource content is returned.

  • Caching scheme

    Last-modify/if-modify-since: When a browser requests a resource for the first time, last-modify is added to the header returned by the server. Last-modify indicates the time when the resource was Last modified. When the browser requests the resource again, the request header contains if-modify-since, which is the last-modify returned before the cache. After receiving if-modify-since, the server determines whether the resource matches the cache based on the last modification time

    Etag/ if-none-match: When the Web server responds to a request, it tells the browser the unique identifier (Etag) of the current resource on the server (the generation rule is determined by the server). When a resource expires (using the max-age identified by cache-control) and the resource is found to have an Etag declaration, the web server requests the resource again with if-none-match (the Etag value). After receiving the request, the Web server finds the if-none-match header and compares it with the corresponding checksum string of the requested resource to determine whether the negotiated cache is matched.

The local cache

1, cookie,

  • 1. Compatible with all browsers
  • 2. The storage size is limited. Generally, a source (in a domain) can only store 4KB of content
  • 3. Cookies have expiration time (of course, we can set this time manually)
  • 4. Antivirus software or browser garbage cleaning may forcibly remove cookie information
  • 5. Cookies are not recorded in private or traceless browsing mode
  • 6. Cookies are not strictly local storage because they are transmitted back and forth to the server

2, localStorage

  • 1. Incompatible with IE8 and below –
  • 2. The storage capacity is also limited. A maximum of 5MB can be stored in one source
  • 3. Local permanent storage, as long as you do not manually delete, will always be stored locally (but we can manually remove some of the information we want to remove based on the API removeItem/ Clear)
  • 4. Antivirus software or browser garbage cleaning will not clear localStorage for the time being (the new version of Google Chrome will clear localStorage and other information)
  • 5. Record localStorage in private or traceless browsing mode
  • LocalStorage has nothing to do with the server
3, sessionStorage
  • The only difference between sessionStorage and localStorage is that sessionStorage is temporary storage and only valid for the current call. SessionStorage is invalid when the current TAB page of the browser is closed. It has the same method as localStorage.

Both localStorageh and sessionStorage have about 5M storage space and are not suitable for storing large amounts of data. For large data caches, local database implementation (indexDB) should be applied.

4, indexDB

IndexedDB has the following characteristics.

  • (1) Key-value pair storage.

    IndexedDB uses an object Store internally to store data. All types of data can be stored directly, including JavaScript objects. In the object warehouse, data is stored as “key-value pairs”. Each data record has a corresponding primary key. The primary key is unique and cannot be duplicated, otherwise an error will be thrown.

  • (2) asynchronous.

    IndexedDB does not lock the browser and users can still perform other operations, in contrast to LocalStorage, where operations are synchronous. Asynchronous design is designed to prevent massive data reads and writes from slowing down the performance of a web page.

  • (3) Support transactions.

    IndexedDB supports transaction, which means that if one of a series of steps fails, the entire transaction is cancelled and the database is rolled back to the state before the transaction occurred, without overwriting only a portion of the data.

  • (4) Homologous restriction

    IndexedDB is subject to the same origin restriction, with each database corresponding to the domain name that created it. Web pages can only access databases under their own domain names, but not cross-domain databases.

  • (5) Large storage space

    IndexedDB has much more storage space than LocalStorage, usually no less than 250MB or even no upper limit.

  • (6) Support binary storage.

    IndexedDB can store not only strings but also binary data (ArrayBuffer objects and Blob objects).

Based on thelocalforageVue project local cache data to indexDB database instance code
<script type="text/ecmascript-6"> import localforage from 'localforage' export default { data () { return { db: null, canIndexedDB:false } }, mounted () { this.initIndexedDB() }, methods: { async getStoreList (key) { let resData = [] if ( ! this.canIndexedDB){ resData = getAllData() }else{ let cache = await this.db.getItem(key) if (cache) { resData = cache }else{ resData = getAllData() } console.log(resData); }} initIndexedDB () { this.canIndexedDB = localforage.supports(localforage.INDEXEDDB) if (this.canIndexedDB) { this.db =  localforage.createInstance({ name: 'cacheName', driver: localforage.INDEXEDDB }) window.db = this.db } else { this.db = null } }, }, } </script>Copy the code