Article directory
Problem background
The front-end page has been developed and tested and needs to be put online. After some pages are uploaded and updated to the server, the browser is not updated and the old page is still rendered. This is caused by the browser reading the cache. You need to clear the cache and refresh to see the page updates. But some users are unaware of these operations.
Therefore, it is necessary to solve the problem of the browser not updating after the file is changed.
1. Solution
1. The entry file is not cached or cached through negotiation; other static resource files are cached, and then the URL of each file is requested to be spliced into a hash value or the file name is added to the hash value when packaging. This hash value can be calculated based on the file. . (Compare the URL address, if the URL address is different, the cache will not be used)
2. Prompt the user to clear the cache.
2. Implementation principle
About caching
What is caching? The first time a user accesses files, data, styles and other resources, they must request them from the server, and the browser will have nothing. The second visit does not require repeated requests and can be obtained from the cache.
Why do you need caching? From entering the URL to loading the page, CPU calculations and page rendering are relatively fast, but the slowest thing in the whole process is the network request, which can reach hundreds of milliseconds or one second. Therefore, try to reduce the number and volume of network requests to make it faster.
Using caching, you can optimize performance, do not need to request the server every time, save traffic, reduce server pressure, and improve loading speed
Disadvantages: cache content and server data Inconsistent; consumes memory.
What resources can be cached? Static resources (js css img) (webpack can configure hash, and it can be updated after the file is changed, without using cache)
Browser caching is generally for static resources (js/css/img, etc.). Whether or not caching is required can be controlled based on the fields returned by the server.
Cache-related headers:
- Cache-Control: request header/response header. The server thinks it can be cached, so it adds Catch-Control to the request header. Control caching policies
- Expires: response header, representing resource expiration time
- Last-Modified: response header, the last modification time of the resource
- If-Modified-Since: Request header, the last modification time of the resource. (Paired with Last-Modified. That is, take it from the response header and tell the server)
- Ttag: response header, resource identifier
- If-None-Match: Request header, cache resource identifier. (Paired with Etag, told by the browser to the server)
Strong caching
The server returns the cache, and the server decides whether to cache it. For example, if Catche-Control sets max-age=180000, then after this period of time, the cache will expire before requesting the server. Or, if the resource name changes, it will be updated before the cache expires.
Cache-Control value:
- max-age: The cache will expire in xxx seconds;
- no-cache: Do not want to do caching, let the server handle it;
- no-store: No local caching or server caching is required.
- private: allows users to cache, but proxy servers cannot;
- public: Cacheable by both client and proxy server
Negotiate cache
The client makes the first request, and the server returns the resource and resource identifier.
Request again with the resource identifier; the server determines whether the resource has changed based on the resource identifier.
If there is no change, return 304; if there is a change, return 200 and new resources.
Resource identifiers are (in Response Headers):
- Last-Modified The last modification time of the resource. If-Modified-Since is included in the request, the server can determine whether the modification time is the same. If it is different, it means it has been modified.
- Etag The unique identifier of the resource. Its value can be calculated based on the file, and If-None-Match is included in the request. The server compares this value to determine whether to modify it.
Etag solves the problem that Last-Modified cannot be modified:
1. Some files may change periodically, but the content remains unchanged. At this time, you don't want the client to think that the file has been modified.
2. The file is modified very frequently, and it is modified within seconds or less. The granularity that If-Modified-Since can check is at the second level. This kind of modification cannot be judged.
3. Some servers cannot accurately obtain the last modification time of the file.
The impact of refreshing the page on the browser
Normal operation: Enter url, link jump, forward and backward. Both forced caching and negotiated caching are valid.
Manual refresh: F5, click the refresh button, right-click the menu to refresh. Force cache invalidation, negotiation cache is useful.
Force refresh: ctrl + F5. Force cache invalidation, negotiate cache invalidation
Summarize
The caching mechanism of http is an optimization strategy. However, there may also be problems with the browser not updating after file changes. In summary, entry files are not cached or negotiated cache is used. Other static resources use strong caching, URL splicing hash values or adding hash values to the file name when packaging.