HTTP cache

By reusing previously acquired resources, you can significantly improve the performance of your web site and application. Web caching reduces wait time and network traffic, thus reducing the time required to display resource representations. Become more responsive by using HTTP caching.

Different kinds of caches

Caching is a technique for saving a copy of a resource and using it directly on the next request. When the Web cache discovers that the requested resource has been stored, it intercepts the request and returns a copy of the resource rather than going to the source server to download it again. The benefits include: reduced server-side stress and improved performance. Caching is an important part of achieving high performance for web sites. Caches need to be configured properly, because not all resources are permanent: it is important that the cache of a resource expires until the next time it changes (i.e., an expired resource cannot be cached).

There are many types of caches, which can be roughly grouped into two categories: private and shared caches. Responses stored in a shared cache can be used by multiple users. Private caches can only be used by individual users. This article will mainly introduce browser and proxy cache, in addition to gateway cache, CDN, reverse proxy cache and load balancer deployed on the server, to provide better stability, performance and scalability for sites and Web applications.

Private) browser cache

Private caches can only be used by individual users. You’ve probably seen the “cache” option in your browser Settings. The browser cache holds all documents downloaded by the user over HTTP. These caches provide backward/forward navigation of browsed documents, save web pages, view source code, and other functions to avoid making redundant requests to the server again. It also provides offline browsing of cached content.

(Shared) proxy cache

The shared cache can be used by multiple users. For example, an ISP or your company might set up a Web proxy to provide to users as part of the local network infrastructure. Hot resources can then be reused, reducing network congestion and latency.

The target of the cache operation

Although HTTP caching is not required, it is often necessary to reuse cached resources. However, common HTTP caches store only GET responses, not other types of responses. The key to caching is the Request Method and the target URI (usually only GET requests are cached). Common cache cases:

  • A successful response to a retrieval request: for a GET request, the response status code: 200 is considered successful. A response that contains, for example, an HTML document, image, or file.
  • Permanent redirect: Response status code: 301.
  • Error response: a page with response status code 404.
  • Incomplete response: Response status code 206, only partial information is returned.
  • If a response is matched as a defined cache key name, except for a GET request.

For some specific requests, keywords can also be used to distinguish between different responses stored in multiple stores to form the contents of the cache. For specific reference [below](developer.mozilla.org/zh-CN/docs/… Responses) information about Vary.

The cache control

Cache-control 头

The cache-control header defined in HTTP/1.1 is used to distinguish between support for caching mechanisms, and is supported by both request and response headers. Caching policies are defined by the different values it provides.

There is no cache

Nothing about client requests and server responses can be stored in the cache. The complete response is downloaded for each request initiated by the client.

Cache-Control: no-store
Copy the code

Cache but revalidate

As defined in the header below, each time a request is made, the cache sends the request to the server, which verifies that the cache described in the request is expired. If it is not, the cache uses the local cache copy.

Cache-Control: no-cache
Copy the code

Private and public caches

The “public” directive indicates that the response can be cached by any intermediate proxy, CDN, etc. If “public” is specified, pages that would not normally be cached by middlemen will be cached by middlemen.

“Private” means that the response is dedicated to a single user. The intermediate proxy cannot cache the response, and the response can only be used in the browser’s private cache.

Cache-Control: private
Cache-Control: public
Copy the code

overdue

The most important instruction in the expiration mechanism is “max-age=

“, which indicates the maximum amount of time a resource can be cached (kept fresh). In contrast to Expires, max-age is the number of seconds since the request was initiated. For files that do not change in an application, you can manually set the duration to ensure that the cache is valid, such as static resources such as images, CSS, and JS.

See caching effectiveness below for more details.

Cache-Control: max-age=31536000
Copy the code

Verify the way

When the “must-revalidate” directive is used, it means that when the cache considers using an obsolete resource, its state must be verified and the expired cache will not be used. See more about cache validation below.

Cache-Control: must-revalidate
Copy the code

Pragma 头

Pragma is a header property defined in the HTTP/1.0 standard. The effect of the Pragma included in the request is defined in the cache-control header: No-cache is the same, but the HTTP response header does not explicitly define this property, so it is not a complete replacement for the cache-control header defined in HTTP/1.1. Pragma is generally defined for backward compatibility with HTTP/ 1.0-based clients.

The refresh

In theory, when a resource is cached, it should be permanently stored in the cache. Because caches have limited space to store copies of resources, caches periodically remove copies, a process called cache eviction. On the other hand, when the server resources updated above, the corresponding resources should also be updated in the cache, because HTTP protocol is C/S mode, the server to update a resource, can’t be directly to notify the client cache updates, so both parties must agree to the resource an expiration time, before the expiration time, The resource (cache copy) is fresh and becomes stale when the expiration time passes. * evict algorithm is used to the resources of the old (cached copy) replaced by fresh, note that an old resource (cached copy) is not directly be cleared or ignored, when the client initiates a request, caching retrieved for a corresponding old resources (cached copy), the cache will attach the request an If – None – Match head, If the server returns 304 (Not Modified), the resource copy is fresh, which can save some bandwidth. If the server determines that the resource has expired by if-none-match or if-modified-since, the entity content of the resource is returned.

Here is a diagram of the caching process described above:

For requests with a particular header, the cache lifetime is calculated. For example, cache-control: max-age=N, the corresponding Cache lifetime is N. Typically, requests that do not contain this attribute are checked to see if the Expires attribute is included, and the cache is still valid by comparing the Expires value to the Date attribute in the header. If neither max-age nor Expires attributes are present, look for last-Modified information in the header. If so, the lifetime of the cache is equal to the Date value in the header minus the last-modified value divided by 10.

The calculation formula of cache invalidation time is as follows:

expirationTime = responseTime + freshnessLifetime - currentAge
Copy the code

In this case, responseTime represents the point in time at which the browser received the response.

To improve the resources

The more we use cached resources, the better the responsiveness and performance of the site will be. To optimize caching, it is a good policy to set expiration times as long as possible. This is safe for resources that are regularly or frequently updated, but can be problematic for resources that are not updated for a long time. These fixed resources benefit from this long-term caching strategy for a while, but are difficult to update once they are updated. Js/CSS files introduced on web pages that need to be updated as soon as possible when they change.

Web developers invented a technique called Revving by Steve Souders [1]. Files that are infrequently updated are named in a specific way: the version number is appended to the URL (usually the file name). A resource with a version number is treated as a completely new and independent resource with a cache expiration period of one year or more. The downside is that all references to the resource need to be updated. Web developers often use automated build tools to do these chores in the real world. When the low frequency updated resource (JS/CSS) changes, only make entry changes in the high frequency updated resource file (HTML).

Another advantage of this approach is that updating both cache resources at the same time does not cause part of the cache to be updated first, causing the contents of the new and old files to be inconsistent. For CSS and JS files that depend on each other, it is important to avoid such inconsistencies.

The version number appended to the accelerator file does not have to be an official version number string, such as 1.1.3 or other fixed incremented version numbers. It can be any token to prevent cache collisions such as a hash or a timestamp.

Cache validation

Cache validation starts when the user hits the refresh button. If the cached response header contains a “cache-control: must-revalidate” definition, the Cache validation will also be triggered during browsing. In addition, setting Advanced->Cache to force validation caching in browser preferences can achieve the same effect.

When a cached document expires, you need to validate the cache or retrieve resources. Validation occurs only if the server returns a strong or weak validator.

ETags

As a strong validator for the cache, the ETag response header is a value that is opaque to the User Agent (UA). For HTTP UAs like browsers, you don’t know what ETag stands for, and you can’t predict what its value will be. If the resource request has an ETag in the response header, the client can apply if-none-match headers to subsequent requests to verify the cache.

The last-Modified response header can serve as a weak validator. Weak because it can only be accurate to one second. If the response header contains this information, the client can validate the cache with if-modified-since on subsequent requests.

When a request is made to the server for cache validation, the server returns either 200 OK indicating a normal result or 304 Not Modified indicating that the browser can use the local cache file. The 304 response header can also update the expiration time of cached documents.

Than the response

Vary HTTP response headers determine how to decide whether to request a new resource or use a cached file for subsequent headers.

When the cache server receives a request, the cached response can only be used if the current request and the original (cached) request header match the Vary in the cached response header.

Using the Vary header facilitates dynamic diversity of content services. For example, with the Vary: user-Agent header, the cache server needs the UA to determine whether to use the cached page. If you need to differentiate between mobile and desktop displays, this way you can avoid displaying the wrong layout on different terminals. In addition, it can help Google or other search engines better discover mobile versions of pages and tell search engines that Cloaking is not being introduced.

Vary: User-Agent
Copy the code

Because the mobile version is different from the user-Agent in the desktop client’s request header, the cache server does not mistakenly output the mobile content to the desktop to the User.

The cache-control header

Cache-control A generic header field used to specify directives to implement caching in HTTP requests and responses. Cache directives are one-way, which means that directives set in the request are not necessarily included in the response.

Header type General header
Forbidden header name no
CORS-safelisted response-header yes
grammar

The instruction format has the following valid rules:

  • Case insensitive, but lower case is recommended.
  • Multiple instructions are separated by commas.
  • Optional arguments, either token or quoted string syntax.

Cache request instruction

A standard cache-control directive that clients can use in HTTP requests.

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached
Copy the code

Cache response instruction

Standard cache-control instructions that the server can use in response.

Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>
Copy the code

extensionCache-Controlinstruction

The extended cache directive is not part of the core HTTP cache standard document. Please check compatibility before using it.

Cache-control: immutable
Cache-control: stale-while-revalidate=<seconds>
Cache-control: stale-if-error=<seconds>
Copy the code

The cache can be

  • public

    Indicates that the response can be cached by any object (including the client that sent the request, the proxy server, and so on), even content that is not normally cacheable. (E.g. 1. The response does not have a Max-age directive or Expires header; 2. The request method corresponding to this response is POST.

  • private

    Indicates that the response can only be cached by a single user and not as a shared cache (that is, the proxy server cannot cache it). The private cache can cache the response content, for example, the corresponding user’s local browser.

  • no-cache

    The cache is forced to submit the request to the original server for validation (negotiated cache validation) before the cache copy is published.

  • no-store

    The cache should not store anything about the client request or the server response, that is, no cache is used.

Due to

  • max-age=<seconds>

    Sets the maximum period for which the cache is stored, after which the cache is considered expired in seconds. In contrast to Expires, time is the time relative to the request.

  • s-maxage=<seconds>

    Overrides max-age or Expires headers, but only for shared caches (such as individual agents) and private caches ignore them.

  • max-stale[=<seconds>]

    Indicates that the client is willing to accept an expired resource. An optional number of seconds can be set to indicate that the response cannot be out of date beyond that given time.

  • min-fresh=<seconds>

    Indicates that the client wants to get a response that will keep it up to date for a specified number of seconds.

  • stale-while-revalidate=<seconds>

    Indicates that the client is willing to accept stale responses while asynchronously checking for new ones in the background. The second value indicates how long the customer is willing to accept stale responses.

  • stale-if-error=<seconds>

    Indicates that the customer is willing to accept the stale response if the new check fails. The second value represents how long the customer is willing to accept stale responses after the initial expiration.

Revalidate and reload

  • must-revalidate

    Once a resource expires (such as if it has exceeded max-age), the cache cannot respond to subsequent requests with the resource until it is successfully validated to the original server.

  • proxy-revalidate

    It has the same effect as must-revalidate, but applies only to shared caches (such as proxies) and is ignored by private caches.

  • immutable

    Indicates that the response body does not change over time. Resources (If not expired) do not change on the server, so the client should not send a revalidation request header (such as if-none-match or if-modified-since) to check for updates, even If the user explicitly refreshes the page. In Firefox, immutable is only used in https:// transactions. See here for more information.

other

  • no-transform

    Resources may not be converted or converted. HTTP headers such as content-encoding, content-range, and Content-Type cannot be modified by the proxy. For example, an opaque proxy or something like Google’s Light Mode might convert image formats to save cache space or reduce traffic on slow links. The no-transform directive does not allow this.

  • only-if-cached

    Indicates that the client accepts only cached responses and does not check with the original server for newer copies.

Prohibit the cache

To turn off the cache, send the following response header. In addition, you can refer to Expires and Pragma headers.

Cache-Control: no-store
Copy the code

Caching static resources

For files that don’t change in your application, you can usually add an active cache before sending a response header. This includes static files such as images, CSS files, and JavaScript files provided by the application. See also the Expires header.

Cache-Control:public, max-age=31536000
Copy the code

Need to revalidate

If no-cache or max-age=0 is specified, must-revalidate indicates that the client can cache the resource. Each time a cache resource is used, it must be validated again. This means that an HTTP request is made each time, but the download of the HTTP response body can be skipped while the cached content is still valid.

Cache-Control: no-cache
Cache-Control: max-age=0, must-revalidate
Copy the code

Note: If the server is down or disconnected, the following instructions may cause caching to be used.

Cache-Control: max-age=0
Copy the code

reference

  • RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
  • Caching Tutorial — Mark Nottingham
  • HTTP caching – Ilya Grigorik
  • RedBot, a tool for checking cache-relevant HTTP headers.