We all know that caching pages helps reduce the number of requests sent and optimizes the page. However, in my front-end working life, I always thought that the front-end was just a writing page and writing interaction, which was already great. This kind of idea without ambition led to the bottleneck in my future work. A man must have a dream, or he will be no different from a salted fish. I’ve been talking about front-end optimization lately, and it turns out that caching pages effectively improves response times. I am also a synthesis of their own to see a few articles, talk about views, as a study notes, what is wrong, please forgive. Without further ado, let’s get down to business.

Caching mechanisms

Caching is divided into the server side (such as Nginx, Apache) and the client side (such as Web Browser).

Server side cache is divided into proxy server cache and reverse proxy server cache (also called gateway cache, such as Nginx reverse proxy, Squid, etc.), in fact, the widely used CDN is also a server side cache, the purpose is to let users take the request “shortcut”, and are cache pictures, files and other static resources. HTML Meta tags vs. HTTP headers < Meta http-equiv =”Pragma” CONTENT=”no-cache”> This code tells the browser that the current page is not cached and needs to be pulled from the server every time it is accessed. It is simple to use, but only some browsers support it, and none of the caching proxy servers support it because the proxy does not parse the HTML content itself.



1. Server cache

What is the Etag? What is the last-modified? Wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait.

Cache-control, if-none-match, if-modified-since, Etag, Expires, last-Modified, Request header Cache: cache-control: the cache instruction for the first segment has the following values: no-cache, no-store, and max-age. No-cache: The actual data is cached locally, but each request directly bypasses the cache and requests the latest resources directly to the server. Due to different interpretations of browsers, for example, after no-cache is set in IE, the request does not directly use cache. However, it also uses cache data to check for consistency with server data. Firefox ignores no-cache completely, as explained in no-store. No-store: Indicates that the cache does not store the response portion of this request. In contrast to no-cache, one does not cache and the other does not store cache. The no-store option is used to disable the cache, but the implementation of this option varies greatly between browsers. This option is used to prevent the cache from being compromised by malicious changes to the storage path. In Firefox, you can save a copy of the cache to a local file by saving it as a file. Using no-cache directly does not work for it. If you add the no-store setting, you can have the same effect as no-cache. Namely: the cache-control: no – cache, no – the store; Can ensure that in support of HTTP1.1 versions of major browsers hit Hit back refresh no cache; Pragma: no-cache is compatible with version 1.0 (but in case of conformance checking, it is better to add conformance checking content, as shown below). Max-age: for example, cache-control: max-age=3. If the same request is sent within 3 seconds after the request is successful, the local cache is used instead of the server. Similarly, if max-age=0 is set to immediately discard the cache and directly send the request to the server, consistency detection can be divided into two ways: 1. Whether the detection date is expired and whether the detection resources are updated; If-none-match: This field is used with the eTag in the response to check whether the entity has changed. The client sends a request first time response packet contains field Etag, resource state, when resources are changing this value will also change after (client don’t care about how the value generated) then caches store under the field, have been the second time the cache time when browsing the local cache is to assign the value to the if – none – match field sent to the server, The server will compare the sent value with the current state. If the value is the same, it will reply 304 to use the cached data. If the value changes, it will send the latest data to the client to replace the existing cached data, and return status 200. if-modified-since: This field is used in combination with the last-Modified field. In this case, the responder first returns a last-Modified time field, and the request header assigns the last-Modified field from the cache to if-Modified-since. If not, it returns 304, tells the client to use cached data, and if it expires, returns a last-Modified and returns 200. Repsonse header Cache related: Etag: Used in conjunction with if-none-match, it generates a hash string (similar to MD5 or SHA1) based on the entity content to identify the state of the resource. When the resource send changes, the ETag changes with it. Etag is mainly used to solve problems that cannot be solved according to the time. For example, files are frequently modified (within seconds), which makes it impossible to determine whether to update files according to the time. And expires: The time is changed, but the content is the same. Example: Expires :Mon Dec 30 2011 11:01:19 GMT. This is the same as max-age in cache-control, but is overwritten and replaced by max-age when it is encountered. Last-modified: indicates the time when the file is last modified. In addition, the cache-content of the response header is similar to that of the request

Using caching:

By default, browsers use cached data,

In the case of F5 refresh, the browser will send a consistency verification to the server to verify whether the cache is used, and the browser directly enters the press enter to indicate that the cache is directly applied without going to the server to verify. So we will explain the implementation using cache as f5 refresh:

By default, both the server and the front end use cached data, either based on eTAG or based on max-age or based on Expires, depending on the server;

In practice, most of them do not need to be implemented manually, but in some cases we are not sure whether to use caching we can manually intervene to force the use of cached data:

For example, a static file that includes HTML or images and we need to use caching to speed things up,

Method one:

The server configures its max-age or expires to set an expiration value one year after the current one. This will use the files in the cache each time the validation is performed. For example, in.htaccess

<IfModule mod_headers.c>

<FilesMatch “.(gif|jpg|jpeg|png|ico)$”>

Header set Cache-Control “max-age=604800”

</FilesMatch>

Method 2:

If-modified-since is set to a date when the last modification was greater than the current date.

Method 3:

The server determines whether a match is made according to the ETAG and uses the cache according to the actual business.

The latter two methods are weakly cached data headers and need to waste HTTP connections. Therefore, the first method is recommended.

To disable caching:

Method one:

<meta http-equiv=”pragma” content=”no-cache”>

<meta http-equiv=”cache-control” content=”no-cache”>

<meta http-equiv=”expires” content=”0″>

Method 2:

You can also go to setRequestHeader dynamically and force no cache Settings as follows:

cache-control=’no-cache,no-store’

pragma=’no-cache’

if-modified-since=0;

Method 3:

The requestor sets if-modified-since to some time that has expired, which can be years or decades ago.

Method 4:

The server sets Expires to an expiration date, such as header(“Expires: Mon, 26 Jul 1997 05:00:00 GMT”) in PHP.

In the actual development, if consistency detection is needed, Etag and Last-Modified will be used as far as possible for comparison and then return to use cache or new data; This one is a bit server-side, so I won’t repeat it

Method 5:

Url += “&random=” + math.random () this method is often used in JAVASCRIPT and PHP. If the requested URL is not found in the cache, the server will automatically search for the latest resource.

2. Browser cache

Browser cache is an optimized mechanism for the browser to store data for fast reading or to avoid repeated resource requests. The effective use of cache can avoid repeated network requests and the browser can quickly read local data, and accelerate the presentation of web pages to users as a whole. There are many different mechanisms for caching on the browser side. Open the browser debug mode -> Resources and you can see the 8 mechanisms for caching on the browser side.



The js cache mechanism above has related APIS for operation, please query by yourself. In fact, I pasted and copied all of them, because these articles made me feel enlightened at that time. Please refer to the following links for details

1, write front-end HTTP cache details

2. Nine caching mechanisms on the browser side are introduced

3. HTTP caching improves performance