Category: Static resource caching
About static resource cache configuration, mainly back-end development work, front-end development students must have a certain understanding but not in-depth.
Today we will take a thorough look at static resource caching:
- What is the definition of static resource caching?
- What are the classification and application scenarios of static resource caching?
- How to implement static resource caching, what is the current mainstream way?
First of all, let’s start with a small story: Student C is a front-end program ape, responsible for the maintenance of the company’s portal website. One day, his boss threw him a 5M large picture and asked him to put it on the front page of the website. Such a large resource, if every time the user opens the website after all have to request again from the server, will inevitably cause the user load speed slow down and bandwidth waste. So our clever hero came up with a caching method: cache the image resources locally, and the next time we need this resource, we don’t need to request network resources, but directly read from the cache.
So the small C student opened the code trip again…
Cache classification
The cache exists in HTTP GET requests. The browser can intelligently determine whether to use locally stored content or the content returned by the server based on the values of the header fields in the request and response, and the client time.
- Negotiation cache 304: The server determines whether to obtain resources from the cache after the request is sent to the server. If the file does not change, the server obtains resources from the cache. If the file changes, the server obtains new resources.
- Strong cache 200: The request sent by the user is directly obtained from the client cache before the cache time expires. The request is not sent to the server or interacts with the server.
There are two types of strong caches: disk cache and memory cache
- Disk Cache: Caches resources to disks. The CurlCacheManager directly obtains resources from disks without re-downloading them for next access. The main difference with memoryCache is that, when exiting a process, the data in memory is cleared, but the data in disk is not. Therefore, the next time you enter a process, the process can still fetch data from diskCache, whereas memoryCache cannot.
- Memory cache: Caches resources to the memory and obtains resources from the memory without re-downloading them. 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.
What happens when you send the HTTP request
The request for the first time
- The client requests a resource
- The server returns the resource and adds the cache-Control/Expires, last-Modified /ETag fields to the Response header
- The client presents the page and stores the page with the fields in the header to request it again
- If there is a cache-control/ Expires field, compare it to the client’s time to determine whether the cache has expired. If not, use the cache resource and return 200(from disk cache) or 200(from memory cache). Send a request to the server
- When sending a request to the server, if there is a last-Modified /ETag field locally, the last-Modified /ETag field of the Last request is passed to the server together with the last-Modified /ETag field of the Last request, and the server resources are compared to determine whether the resource has changed since the Last request. If there is no change, 304 and an empty response body are returned. Otherwise return 200 and the new resource
Configuration of static resource caching
Fields associated with the 200 cache
-
Set Expires to a Date string with a lower priority than cache-control. If both Expires and cache-control are set, the latter takes effect. One obvious disadvantage of this approach is that the expiration time is an absolute time, so when the client local time is changed, the server and client time deviation becomes large, resulting in cache confusion.
-
Cache-control: Sets the relative expiration time, in seconds, that is always compared with the client time.
No-cache: Data cannot be cached and the server is re-accessed for each request. If max-age exists, the server is not accessed during the cache.
No-store: not only can’t cache, but also can’t temporarily store the resource (i.e., can’t temporarily store the resource in temporary folder)
Private (default): Cache only in the browser. The server is accessed only on the first request. If max-age exists, the server is not accessed during cache
Public: can be cached by any cache, such as browser, server, proxy server, etc
Max-age: indicates the relative expiration time of the cache in seconds
Fields related to the 304 cache:
-
Etag Etag returns a resource ID(string) to the browser, normally sent with the new ID if a new version is available, otherwise 304 is returned. Etag is designed to solve the problem that last-Modified is only accurate to seconds, and can be accurate to milliseconds. But in the case of server clustering, you must ensure that each distributed server returns the same ETag.
-
Last-Modified: The next time the browser requests a resource, the browser will first send a request to the server with the if-odified -Since header indicating the last modification time of the resource cached by the browser. If the server finds that the resource has not been modified, The 304(Not Modified) response message is returned directly to the browser (very little), and if the server compares the time and finds that it has changed, the requested resource is returned as usual.
Implementation of static resource caching
Storage location
Resources are cached on the user’s computer in a browser directory. MAC OS, chrome browser Cache storage location is: / Users/XXX/Library/Caches/Google/chrome/Default/Cache, the Default Cache file suffix, we can manually add suffix
Implement 304 cache
Effect:
Implement 200 cache
Nginx on the server:
Development environment, do not want to use cache, how to implement
Configure cache-control:no-store on the server to disable the cache of static resources
The production environment forces the cache flushing policy
In the production environment, a user may have a cache of 200. When the resource is changed, the user cannot manually clear the cache. In this case, the old user may display the contents of the cache during the old cache validity period. Solution: Associate the file name with the file content, such as the JS file, and change the file name after each modification of the file content, forcing the user to use the new file, not using the cache.
CDN back to source nginx related configuration step by step optimization field