1. Introduction

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 (less time to acquire resources). 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. — From MDN – HTTP Cache

This article focuses on the browser cache (or private cache). Caching is the most common optimization tool in most scenarios. It is simple and efficient

Advantages of caching:

  • Client: Reuses resources, reduces network overhead, and provides faster response resolution for requests, providing better user experience
  • Network: reduces the Network overhead of redundant resources, saves bandwidth, and reduces costs
  • Server: a simple and efficient means of performance optimization to reduce Server load and avoid performance bottleneck caused by overload

2. Caching mechanism

Common HTTP caches store only GET responses, not other types of responses. The key of cache mainly includes request method and target URI (generally only GET request is cached). The flow chart is as follows:

2.1 strong cache

Strong cache: If a strong cache is hit, the request sent by the browser will not reach the server, but will be directly read from the browser cache. In Chrome Network, the size is displayed as disk cache or Memory cache, and the HTTP status code is 200.

Strong cached fields: Expires (HTTP/1.0), cache-Control (HTTP/1.0), Pragma (HTTP/1.0)

2.1.1 Expires

Is an absolute time, specify the resource expiration time is the server specific point in time, this field exists in the server response header, that is, before this time, directly read browser cache data. A value of 0 indicates a past date, that is, the resource has expired.

The benefits of Expires:

  • HTTP/1.0 product, backward compatibility

  • Absolute time marks the failure time for easy comparison

Disadvantages of Expires:

  • Because the time is absolute, the client can change the local time to invalidate the cache
  • The time sent by the server may be inconsistent with the time on the client
  • The client cannot know if the resource has been modified until the cache expires

2.1.2 Cache-Control

Given the shortcomings of Expires, in HTTP/1.1, a new field, cache-Control, was added to represent the maximum (relative) time a resource Cache can be valid for when a client doesn’t need to send a request to the server.

Cache-control values are as follows:

Common values Fields that
private By default, all content can only be cached by clients, not proxy servers
public All content can be cached (both client and proxy servers, such as CDN)
max-age Represents the maximum time, in s, for which a resource can be cached (kept fresh)
must-revalidate If the max-age time is exceeded, the browser must send a request to the server to verify that the resource is still valid
no-cache Do not use a strong cache. When using cached data, the browser needs to verify the freshness of the cache with the server
no-store In the true sense of the word “do not cache”, everything is not cached, including coercion and comparison
s-maxage Set up shared caches, such as CDN. Max-age and Expires are overridden
max-stale The maximum expiration time that a client is willing to accept an expired resource
min-fresh Minimum freshness that can be tolerated. Indicates that the client is unwilling to accept a response whose freshness is less than the sum of the current age plus the time specified by Min-Fresh

Cache-control benefits:

  • A product of HTTP/1.1 that addresses the issue of time inconsistencies between Expires servers and clients
  • Instructions can be combined to achieve multiple purposes

Disadvantages of cache-control:

  • This is not available in HTTP/1.0

  • The client cannot know if the resource has been modified until the cache expires

2.2 Negotiated Cache

When the strong cache fails or is not set, the client and server determine (negotiate) whether the resource is available by some kind of identifier, so the fields come in pairs. The request header if-modified-since matches the response header last-modified, and the request header if-none-match matches the response header ETag. If a match is made, the HTTP status code is 304.

2.2.1 last-modified and If – Modified – Since

Is the absolute time when the server resource was Last Modified. The Last last-modified value is written to the if-Modified-since field in the request header. Compare the last-Modified and if-Modified-since times of the response header of this request. If the time is consistent, the 304 status code is returned.

Last-modified and if-modified-since advantages:

  • HTTP/1.0 product, backward compatibility

  • Since it is verified by the server each time, there is no problem that the client cannot know whether the resource has been modified

Disadvantages: Last-modified and if-modified-since

  • If the server resource is updated within 1S, multiple changes within 1S May not be recognized
  • If the request is for a dynamic resource, it will not be cached. For example: pages returned by SSR

2.2.2 the Etag and If – None – Match

To address the drawbacks of last-Modified and if-Modified-since, Etag and if-none-match fields were added in HTTP/1.1, which store special identifiers for files (typically Hash generated). For example, the Nuxt.js server renders pages with eTags. In the request header, write the last Etag value to the if-none-match field of the request header. Compare the Etag and if-none-match values of the request header. If the Etag and if-none-match values are consistent, the 304 status code is returned.

Advantages of Etag and if-none-match:

  • This is not available in HTTP/1.0

  • Since it is verified by the server each time, there is no problem that the client cannot know whether the resource has been modified

  • It can more accurately indicate whether the resource content is modified, and can identify the situation that the content is modified several times within 1S

Disadvantages of Etag and if-none-match:

  • To calculateEtagValues impose additional performance costs
  • If the algorithms of the servers in the cluster are inconsistent, this alarm is generatedEtagThe comparison is invalid and cannot play the role of negotiation cache

3. Impact of user behavior on browser cache

The user action Expires/Cache-Control Last-Modied/Etag
Address enter Square root Square root
Page link jump Square root Square root
A new window Square root Square root
Forward, back Square root Square root
F5 to refresh X Square root
Ctrl+F5 Force refresh X X

5. Vary

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.

In short, you can use the Vary field to tell the cache which header fields are used to distinguish between the same URL request and the different content of the response on the server.

6. CDN (Public Cache)

In most front-end projects, static resources use CDN to speed up user access. CDN Cache policies vary from vendor to vendor, but generally the node Cache time is set based on the cache-Control and Expires fields in the response header of the source site. Therefore, cache-Control and Expires returned by CDN caches are typically derived from server or Nginx configurations.

7. To summarize

  • Priority: Strong cache is higher than negotiated cache.Cache-ControlaboveExpires.EtagaboveLast-modified
  • According to the status code, they can be divided into two categories: negotiation cache is 304 and strong cache is 200
  • If the server outputsETag, there is no need to output again Last-Modified.EtagThe modification of resources can be accurately identified
  • EtagNot built-in, some frameworks add it by default, for examplenuxt.js 。nodejsYou can useweak tag

Reference 8.

  • MDN – HTTP cache
  • Wikipedia – CDN
  • Google – CDN