preface

The practice series aims to deepen our understanding of some principles through practice.

Practice series – Front-end routing

Practice series – The Babel Principle

Promises/A+ : Promises/ Promises

Those who are interested can follow the practice series. For the star follow ~

If you think you’ve mastered the browser caching mechanism, you can go straight to the hands-on section

directory

CDN cache // CDN cache // Browser caching // This article will focus on and practiceCopy the code

DNS cache

What is the DNS

The full Name is Domain Name System.

The World Wide Web, as a distributed database of domain names and IP addresses, makes it easier for users to access the Internet without having to remember IP strings that can be read directly by machines. DNS runs on TOP of UDP and uses port 53.

The DNS

Simply put, the process of obtaining the IP address corresponding to the domain name is called domain name resolution (or hostname resolution).

www.dnscache.com (domain name) - DNS resolution -> 11.222.33.444 (IP address)Copy the code

DNS cache

Where there is DNS, there is cache. Browsers, operating systems, Local DNS, and root DNS all cache DNS results to some extent.

The DNS query process is as follows:

  1. First search the browser’s own DNS cache, if present, domain name resolution is complete.
  2. If the browser does not find the corresponding entry in the cache, the browser attempts to read the hosts file of the operating system to check whether the mapping exists. If the mapping exists, domain name resolution is complete.
  3. If no mapping exists in the local hosts file, search for the local DNS server (ISP server or manually configured DNS server). If yes, the domain name is resolved.
  4. If the local DNS server is not found, it sends a request to the root server for a recursive query.

Click here to learn more about DNS resolution

CDN cache

What is the CDN

Full name: Content Delivery Network.

Extract a graphic metaphor to understand what A CDN is.

Ten years ago, there was no such thing as a train ticket agent, let alone 12306.cn. At that time, train tickets could only be purchased in the ticket hall of the railway station. However, the small county where I lived did not have access to train, so I had to go to the railway station in the city to buy train tickets. It took four hours to travel from my home to the county and then to the city, which was a waste of life. Then it was good, there were train tickets in the small county town, and even in the township, can directly buy train tickets at the point of sale, convenient a lot, the people of the city no longer have to queue up at a point of helpless pain to buy tickets.

Simply understand that CDN is the contractor of these agent points (cache server), he provides convenience for ticket buyers, help them in the nearest place (nearest CDN node) with the shortest time (shortest request time) to buy tickets (get resources), so that the queue to the train station ticket hall is less. It also reduces the pressure of the ticket hall (play the role of diversion, reduce the server load pressure).

When users browse the website, CDN will choose a CDN edge node nearest to the user to respond to the user’s request, so that the request of Hainan Mobile users will not run thousands of miles to the server of Beijing Telecom room (assuming the source station is deployed in Beijing Telecom room).

CDN cache

As for the CDN cache, when the browser’s local cache is invalid, the browser sends a request to the CDN edge node. Similar to browser cache,CDN edge node also has a caching mechanism. CDN edge node cache policy varies with service providers, but generally follows the HTTP standard protocol and passes the cache policy in the HTTP response header

Cache-control: max-age // will be mentioned laterCopy the code

To set the CDN edge node data cache time.

When the browser requests data from the CDN node, the CDN node will judge whether the cached data has expired. If the cached data has not expired, it will directly return the cached data to the client. Otherwise, the CDN node will issue a back source request to the server, pull the latest data from the server, update the local cache, and return the latest data to the client. CDN service providers generally provide multiple dimensions based on file suffixes and directories to specify CDN cache time to provide users with more refined cache management.

CDN advantage

  1. CDN node solves the problem of cross-operator and cross-region access, and the access delay is greatly reduced.
  2. Most requests are completed at the edge of the CDN, which acts as a diversion and relieves the load on the source server.

    Click here to learn more about the CDN working process

Browser cache (HTTP cache)

Stare at this picture for 30 seconds

What is browser caching

To put it simply, browser caching is a way for the browser to store all the resources obtained through HTTP locally.

Where do cached resources go?

You may be wondering, the browser stores resources, but where does it store them?

memory cache

MemoryCache, as its name implies, is a cache of resources in memory that can be retrieved from memory without having to re-download the resource for the next access. Webkit has long supported memoryCache.


Currently, Webkit resources are divided into two types: main resources, such as HTML pages or download items, and derived resources, such as embedded images or script links in HTML pages, which correspond to two classes in the code: MainResourceLoader and SubresourceLoader. Webkit supports memoryCache, but only for derived resources, corresponding to the CachedResource class, which holds raw data (CSS, JS, etc.) as well as decoded image data.

disk cache

DiskCache, as its name implies, caches resources to disks. The DiskCache directly obtains resources from disks without re-downloading them for next access. Its direct operation object is CurlCacheManager.

  • |memory cache | disk cache
The same Only some derived resource files can be stored Only some derived resource files can be stored
The difference between The data is cleared when you exit the process Data is not cleared when exiting the process
Storage resources Scripts, fonts, and images are stored in memory Generally, non-scripts are stored in memory, such as CSS

Because the CSS file to load a can render out, we will not read it frequently, so it doesn’t fit into the in-memory cache, but the js script, such as may be performed at any time, if the script in the disk, we need from the disk when executing the script into the memory, so it will make a great IO overhead, lose response could lead to a browser.

Level 3 Caching principle (Access cache priority)

  1. First look in memory, if there is, directly load.
  2. If it is not present in memory, it looks in hard disk, if it is loaded directly.
  3. If not, make a network request.
  4. The requested resource is cached to hard disk and memory.

Classification of browser caches

  1. Strong cache
  2. Negotiate the cache

When the browser requests resources from the server, it first determines whether the strong cache is hit, and then whether the negotiated cache is hit!

Advantages of browser caching

1. Redundant data transmission is reduced

2. Reduce the burden of the server, greatly improve the performance of the website

3. Accelerated the client loading web page speed

Strong cache

When loading resources, the browser checks whether the strong cache is matched based on the header information of the local cache resource. If the strong cache is matched, the browser directly uses the cached resources and does not send requests to the server.

The header information here refers to Expires and Cahe-Control.

Expires

This field is the HTTP1.0 specification, and its value is a time string in the GMT format of an absolute time, such as Expires:Mon,18 Oct 2066 23:59:59 GMT. This time represents the expiration time of the resource, before which the cache is hit. One obvious disadvantage of this approach is that since the outage time is an absolute time, it can lead to cache clutter when the server and client times diverging significantly.

Cache-Control

Cache-control :max-age=3600; cache-control :max-age=3600; Indicates that the validity period of the resource is 3600 seconds. Cache-control In addition to this field, there are several common Settings:

No-cache: negotiates the cache and sends a request to the server to confirm whether the cache is used.

No-store: Disables the cache and requests data again each time.

Public: can be cached by all users, including end users and intermediate proxy servers such as CDN.

Private: the device can be cached only by the browser of the terminal user and cannot be cached by a trunk cache server such as the CDN.

Cache-control and Expires can be enabled at the same time in the server configuration, and cache-control has a high priority when both are enabled.

Negotiate the cache

When a strong cache is not hit, the browser sends a request to the server, which determines whether the cache is hit based on the partial information in the header. If it hits, 304 is returned, telling the browser that the resource is not updated and that the local cache is available.

The header information here refers to last-modify/if-modify-since and ETag/ if-none-match.

Last-Modify/If-Modify-Since

When the browser requests a resource for the first time, last-modify is added to the header returned by the server. Last-modify is a time that identifies the Last modification time of the resource.

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.

If the cache is hit, 304 is returned, the resource content is not returned, and last-modify is not returned.

Disadvantages:

A resource changes over a short period of time, and last-Modified does not change.

Periodic changes. If the resource is Modified back to its original state within a period of time, it is considered acceptable to use the cache, but last-Modified is not, hence the ETag.

ETag/If-None-Match

Unlike last-modify/if-modify-since, Etag/ if-none-match returns a check code. ETag ensures that each resource is unique, and changes in resources lead to changes in ETag. The server determines whether the cache is hit based on the if-none-match value sent by the browser.

Unlike last-Modified, when the server returns a 304 Not Modified response, the response header returns the ETag because it has been regenerated, even though the ETag is unchanged.

Last-modified and ETag can be used together. The server will verify the ETag first. If the ETag is consistent, the server will continue to compare last-Modified, and finally decide whether to return 304.

conclusion

When the browser accesses an already accessed resource again, it does this:

1. Check if the strong cache is hit. If so, use the cache directly.

2. If the strong cache is not matched, the system sends a request to the server to check whether the negotiation cache is matched.

3. If the negotiated cache is matched, the server returns 304 telling the browser to use the local cache.

4. Otherwise, return the latest resource.

Practice deepens understanding

Talk is cheap, show me the code. Let us learn through practice

In practice, note the browser console NetworkDo not tick the button.

Here we only cache-control strong buffering and consultation Cache ETag for practice, other friends ~ your own practice

package.json

{" name ":" webcache ", "version" : "1.0.0", "description" : ""," main ":" index. Js ", "scripts" : {" cache ": "nodemon ./index.js" }, "author": "webfansplz", "license": "MIT", "devDependencies": { "@babel/core": "^ 7.2.2 @", "Babel/preset - env" : "^ 7.2.3", "@ Babel/register" : "^ 7.0.0", "koa" : "^ 2.6.2", "koa - static" : "^ 5.0.0"}, "dependencies" : {" nodemon ":" ^ 1.18.9 "}}Copy the code

.babelrc

{
 "presets": [
   [
     "@babel/preset-env",
     {
       "targets": {
         "node": "current"
       }
     }
   ]
 ]
}
Copy the code

index.js

require('@babel/register');
require('./webcache.js');
Copy the code

webcache.js

import Koa from 'koa'; import path from 'path'; Import resource from 'koa-static'; const app = new Koa(); const host = 'localhost'; const port = 4396; app.use(resource(path.join(__dirname, './static'))); app.listen(port, () => { console.log(`server is listen in ${host}:${port}`); });Copy the code

index.html

<! DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, "/> <meta http-equiv=" x-UA-compatible" content="ie=edge" /> <title  { display: block; width: 100%; } </style> </head> <body> <div class="web-cache"><img src="./web.png" /></div> </body> </html>Copy the code

We used KOA to start a Web server, then used koA-static middleware for static resource configuration, and put index.html and web.png under static folder.

Ok, let’s start the service.

npm run cacheCopy the code

Server is listen in localhost:4396.

Next we open the browser and type in the address:

localhost:4396Copy the code

Perfect ~(ha ha, pig don’t spray me, purely for entertainment)

Ok!!! Now let’s practice strong caching. ~

Cache-Control

webcache.js

import Koa from 'koa'; import path from 'path'; Import resource from 'koa-static'; const app = new Koa(); const host = 'localhost'; const port = 4396; App. use(async (CTX, next) => {// Set response header cache-control Set resource validity to 300 seconds ctx.set({' cache-control ': 'max-age=300'}); await next(); }); app.use(resource(path.join(__dirname, './static'))); app.listen(port, () => { console.log(`server is listen in ${host}:${port}`); });Copy the code



If we refresh the page, we can see that the cache-control of the response header has changed to max-age=300.

Let’s also test the three-level caching principle

We just made a network request and the browser saved web.png to disk and memory.

According to the three-level caching principle, we first look for resources in memory, and we refresh the page.

We see it in the red line, from Memory cache. nice~

Ok, next, let’s close the page and open it again. Since memory is in the process, the page is closed and the resources in memory are freed. Resources on disk are permanent, so they still exist.

According to the principle of three-level caching, if the resource is not found in memory, it will go to the disk to find!

from disk cache !!! Ok, this verifies the three-level cache principle, and I believe you have a deeper understanding of the storage of cache resources.

We just set the expiration date for the resource to 300 seconds, so let’s verify that the cache is invalid.

300 seconds later…

We can see from the return value that the cache is invalid.

Have you gained a deeper understanding of strong caching?

Ok!!! Let’s put negotiation caching into practice. ~

Since the default value of cache-control is no-cache(a negotiated Cache is required, and a request is sent to the server to confirm whether Cache is used or not). So we don’t need to set cache-control here!

ETag

//ETag support for Koa responses using etag.
npm install koa-tag -D
// etag works together with conditional-get
npm install koa-conditional-get -DCopy the code

Here we directly use the off-the-shelf plug-in to help us calculate the ETag value of the file, standing on the shoulders of giants!

webcache.js

import Koa from 'koa'; import path from 'path'; Import resource from 'koa-static'; import conditional from 'koa-conditional-get'; import etag from 'koa-etag'; const app = new Koa(); const host = 'localhost'; const port = 4396; // etag works together with conditional-get app.use(conditional()); app.use(etag()); app.use(resource(path.join(__dirname, './static'))); app.listen(port, () => { console.log(`server is listen in ${host}:${port}`); });Copy the code

Ok. First request.



We find that the return value already has an Etag value.

On subsequent requests, the browser will take the if-none-match request header and assign it to the Etag value of the previous return header and compare it to the Etag value of the return value. If they are, the negotiation cache is matched. Return 304 Not Modified. Let’s verify that ~



Ok, as shown, the above statement is perfectly verified.

Next we modify web.png to verify that the negotiated cache policy is invalid when the resource changes.

The principle is also validated by the practice of negotiating caches, as shown in the figure.

You’re done

Writing an article is really tiring. If you think it will help you, please give star/ Follow support to the author ~

The source address

reference

Cache utilization for front-end performance optimization