Browser cache analysis and browser cache

Browser cache analysis and browser cache

The concept of cache is closely related to both the frontend and backend, and must be combined with the frontend and backend. This article analyzes the concept from the perspective of the previous end.

One interview question that has been asked many times:

What are the concepts related to cache browser requests?

Cache-control, expires...

Does ETag know?

No (is this a magic horse ?)

 

Take Baidu captured by chrome as an example to request a js file:

200 initial request ------------------------------- 304 refresh request -------------------------------

After a large number of queries, the results are summarized as follows:

1: The cache concepts related to the server response received by the browser include:

Cache-Control http1.1 max-age number of seconds when the resource is cached locally (note that the unit is seconds) no-cache browser will not Cache the file, regardless of the refresh, press enter, the latest privite response can only be used as a private cache (e.g ., in a browser), public responses cannot be shared among users and will be cached and shared among multiple users. Normally, if HTTP authentication is required, the response will be automatically set to private Expires: cache expiration time, allowing the client to not check (send requests) before this time, which belongs to http1.0, the priority is lower than the cache-control. based on the time of the client, if the time between the client and the server is inconsistent, the problem may occur. Therefore, the concept of cache-control is introduced in http1.1, Last-modified: The last modification time of the server-side file. if the value is the same as if-Modified-Since of the request, the 304 cached ETag is used: a tag. When the server-side resources are changed, ETag also changes. if the value is the same as if-None-Match in the request, 304 is used for caching. 2. the cache concepts related to browser request sending include:

If-Modified-Since: last modification time of the client cache file last-modified if-none-match: etag value of the Client cache File cache-control: max-age = 0 no-cache Prama: no-cache defined in HTTP 1.0, so to be compatible with HTTP 1.0. pragma: no-cache and Cache-Control: no-cache 3: last-modified and ETag are both used to check whether the files on the server have been modified. Why are they used at the same time? ETag is mainly used to solve some problems that Last-Modified cannot solve. 1. Some servers cannot accurately obtain the last modification time of the file. In this way, the last modification time cannot be used to determine whether the file is updated. 2. Some files are frequently Modified and can be Modified in seconds or less. Last-Modified can only be accurate to seconds. 3. The last modification time of some files has changed, but the content has not changed. We do not want the client to think this file has been modified. 4: How can I re-display the page? 1. refresh 2. browser's rollback button 3. press enter in the address bar. 4. force refresh (command + shift + r) difference: refresh will request the server, if the returned if-none-match and if-modified-since are the same as the etag and last-modified of the server, 304 is returned, and the browser uses the cache, note that the browser rollback request and the address bar carriage return request are both browser actions. The client cache is used directly, that is, the 200 from cache is forcibly refreshed and the request is re-submitted, no. 304, but if the server side sets cache-control: none, no matter which behavior, it will re-request 200 without cache 5: special circumstances, dynamically Loaded js files find this problem from requirejs, in the figure r. js is requirejs. When it was refreshed, it was found that the js file loaded by requirejs was always 200 from cache. At first, it was thought that it was related to the internal implementation of requirejs, and the source code was not cached, every time I use a new script tag request, I start to guess whether it is related to dynamic loading. Then I try to load jquery. The result is that the refresh result after jquery dynamic loading is also 200 from cache, therefore, we can perform dynamic loading on our own. This is also true after testing. We initially determined that the cache is dynamically loaded and then refresh the cache in the browser by default, because it is not very definite, so I consulted the company's Daniel and got a reply:"

When refreshing, The Expires/Cache-Control settings are ignored and the request is sent to the server again.

The resources asynchronously loaded on the page are not affected,

So it will also

"