preface

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

Practice series front-end routing

[Practice series]Babel principle

Promises/A+ specifications

Interested students can pay attention to the practice series. For the star follow ~

For those of you who think you already know the mechanics of caching in the browser, go to the hands-on section

directory

 1.DNS cache// It is not relevant to the title, but it is good to know about it
 2.CDN cache// It is not relevant to the title, but it is good to know about it
 3.Browser cache// This article will focus on the introduction and practice
Copy the code

DNS cache

What is the DNS

Full Name Domain Name System.

A distributed database of domain names and IP addresses mapped to each other on the World Wide Web enables users to more easily 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 an IP address from a domain name is called domain name resolution (or host name resolution).

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

DNS cache

Where there is DNS, there is cache. Browsers, operating systems, Local DNS, root DNS servers, they all do some caching of DNS results.

The DNS query process is as follows:

  1. First, the browser’s DNS cache is searched. If it exists, the domain name is resolved.

  2. If the browser does not find the corresponding entry in its cache, it will try to read the hosts file of the operating system to see whether the mapping exists. If the mapping exists, the 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.

Stamp here to learn more about the DNS resolution process

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 were no train ticket sellers, let alone 12306.cn. At that time, train tickets could only be purchased at the ticket hall of the railway station, but there was no train service in the small county where I lived, so I had to go to the railway station in the city to buy the train tickets, and it took four hours to drive from my home to the county and then to the city, which was a waste of life. Later, the small county city appeared train ticket agent, and even township also has a agent, you can directly in the agent to buy train tickets, a lot of convenience, the city’s people no longer have to wait in a point of helplessness and pain to buy tickets.

Simple understanding of CDN is these agents (cache server) contractor, he provides convenience for ticket buyers, help them in the nearest place (the nearest CDN node) with the shortest time (the shortest request time) to buy tickets (get resources), so that the train station ticket hall queuing people will be less. This reduces the pressure on the ticket hall (serves as a diversion and reduces server load).

When the user is browsing the website, the CDN will select a CDN edge node nearest to the user to respond to the user’s request, so that the request of the user of Hainan Mobile will not go all the way to the server of The computer room of Beijing Telecom (assuming that the source station is deployed in the computer room of Beijing Telecom).

CDN cache

Regarding the CDN cache, after the browser’s local cache becomes invalid, the browser will send a request to the CDN edge node. Similar to browser cache,CDN edge node also has a cache mechanism. CDN edge node caching policies vary from service provider to service provider, but generally follow the HTTP standard protocol, through the HTTP response header

Cache-control: max-age   // This will be mentioned later
Copy 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 is expired. If the cached data is not expired, it will directly return the cached data to the client. Otherwise, the CDN node will send back the 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 specify CDN cache time based on file suffixes and directories to provide users with more refined cache management.

CDN advantage

  1. The CDN node solves the problem of cross-carrier and cross-region access and greatly reduces the access delay.
  2. Most requests are completed at the edge nodes of the CDN, and the CDN serves as a diversion to reduce the load on the source server.

Stamp here to learn more about the CDN process

Browser cache (HTTP cache)

Stare at the picture for 30 seconds

What is browser caching

Simply put, browser caching is the behavior of the browser to store network resources locally.

Where do cached resources go?

So you might be wondering, well, the browser stores resources, so where does it store resources?

memory cache

MemoryCache, as its name suggests, caches resources in memory and waits for the next access without having to download the resources again, but simply retrieves them from memory. Webkit already supports memoryCache. Webkit resources are divided into two categories: 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. Although Webkit supports memoryCache, it is only for derived resources. The class is CachedResource, which holds raw data (CSS, JS, etc.) as well as decoded image data.

disk cache

DiskCache, as the name implies, caches resources to disks and obtains resources directly from disks without re-downloading the resources for the 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 Data will be cleared when exiting the process Data will not be cleared when exiting the process
Storage resources Generally, 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 Cache principle (access cache priority)

  1. First look in memory, if there is, directly load.
  2. If it does not exist in memory, it is searched in hard disk, if it does, it is loaded directly.
  3. If there is none on the hard drive, then the network request is made.
  4. Requested resources are cached to disk and memory.

Classification of the browser cache

  1. Strong cache

  2. Negotiate the cache

When the browser requests a resource from the server, it first determines whether it matches the strong cache, and then determines whether it matches the negotiated cache!

Benefits of browser caching

1. Redundant data transmission is reduced

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

3. Speed up the loading of web pages on the client

Strong cache

When loading a resource, the browser first determines whether the resource matches the strong cache according to the information in the header of the local cache resource. If the resource matches, the browser directly uses the resource in the cache and does not send a request to the server.

The information in the header refers to Expires and cahe-Control.

Expires

This field is the specification for HTTP1.0. 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 because the invalidity time is an absolute time, it can lead to cache clutter when the server and client time biases are large.

Cache-Control

Cache-control :max-age=3600; cache-control :max-age=3600; The resource is valid for 3600 seconds. Cache-control: cache-control: cache-control: cache-control: cache-control: cache-control: cache-control: cache-control

No-cache: Indicates that a negotiated cache is required and a request is sent to the server to confirm whether to use the cache.

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

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

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

Cache-control and Expires can be enabled on the server at the same time. Cache-control has a higher priority when both Settings are enabled.

Negotiate the cache

When the strong cache misses, the browser sends a request to the server, which uses some of the information in the header to determine whether the cache has been hit. If it does, 304 is returned, telling the browser that the resource has not been updated and that the local cache can be used.

The information in the header 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, the server returns a header with last-modify, which indicates the Last time the resource was modified.

When the browser requests the resource again, the request header of the request contains if-modify-since, which is the last-modify returned before caching. After receiving if-modify-since, the server determines whether the cache is hit based on the last modified time of the resource.

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

Disadvantages:

If a resource changes over a short period of time, last-modified does not change.

Periodicity. If the resource is changed back to its original form within a period of time, we think it’s ok to use caching, but last-Modified doesn’t, hence the ETag.

ETag/If-None-Match

Unlike last-modify/if-modify-since, Etag/ if-none-match returns a verification code. ETag ensures that each resource is unique, and changes in resources cause 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 will return the same ETag because the ETag has been regenerated, even if the ETag is unchanged.

Last-modified and ETag can be used together. The server validates the ETag first. If the LAST-Modified is consistent, the server will continue to compare the last-Modified before deciding whether to return 304.

conclusion

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

1. Check to see if the strong cache is hit. If yes, use the cache directly.

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

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

4. Otherwise, the latest resource is returned.

Practice deepens understanding

Talk is cheap, show me the code. Let’s get real knowledge through practice

In practice, pay attention to the browser console Network


Do not tick the button.

We only use strong Cache Control and ETag for negotiation Cache. Others can use ETag for negotiation Cache

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';
// Static resource middleware
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


      
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="Width = device - width, initial - scale = 1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>The front-end cache</title>
    <style>
      .web-cache img {
        display: block;
        width: 100%;
      }
    </style>
  </head>
  <body>
    <div class="web-cache"><img src="./web.png" /></div>
  </body>
</html>

Copy the code

We started a Web server with KOA, then used the middleware koA-static to configure static resources, and placed index.html and web.png in the static folder.

Ok, let’s start the service.

npm run cache
Copy the code

Server is listen in localhost:4396.

Next we open a browser and type in the address:

localhost:4396
Copy the code

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

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

Cache-Control

webcache.js

import Koa from 'koa';
import path from 'path';
// Static resource middleware
import resource from 'koa-static';
const app = new Koa();
const host = 'localhost';
const port = 4396;

app.use(async (ctx, next) => {
 Cache-control Sets the resource validity period 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

By the way, let’s verify the three-level caching principle

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

So based on level three caching, we’re going to look for resources in memory, and we’re going to refresh the page.

We see that in the red line, from memory cache. nice~

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

According to the principle of level 3 cache, if the resource is not found in memory, it will search the disk!

from disk cache !!! Ok, above also verify the principle of level 3 cache, believe you also have a deeper understanding of the storage of cache resources.

We just set the resource validity period to 300 seconds, so let’s verify that the cache is invalid.

300 seconds later…

As we can see from the return value, the cache is invalid.

Do you have a better understanding of strong caching?

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

Because the default value of cache-control is no-cache(you need to negotiate the Cache, send a request to the server to confirm whether to use the Cache). , so we don’t need to set cache-control here!

ETag

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

Here we directly use the ready-made 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';
// Static resource middleware
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. The first request.

On subsequent requests, the browser will take the if-none-match request header, assign the Etag value of the last return header, and compare it to the Etag value of the return header. If yes, the negotiation cache is matched. Return 304 Not Modified. Let’s check it out

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

As shown in the figure, the practice of negotiating caching also proves the principle.

You’re done

Writing articles is really a tiring thing, if feel helpful to you, please give star/follow the author ~

The source address

reference

Cache utilization for front-end performance optimization