What exactly is HTTP caching?

When we first go to a web page and refresh it again, it will be much faster than the first time loading. Many people know that this is browser cache, but can’t say exactly what it is, which is exactly the question interviewers like to ask….

What is an HTTP cache

First of all, what is an HTTP cache?

When the client sends a request to the server, it will reach the browser cache first. If the browser cache has the required resource file, it can retrieve the file directly from the cache without sending the request. The advantage of this is to optimize browser performance and avoid repeated requests. Obviously, HTTP caching starts on the second request.

The browser’s first request for resources (HTML, CSS, JS…) The server returns the resource and returns the header information, which includes the cache parameters. When the browser makes a second request, the browser determines the request parameters and returns the status code 200 if the request is in the strong cache. Otherwise, it adds the request parameters to the header and sends it to the server to see if the negotiated cache (weak cache) is hit. If the request is in the weak cache, it returns 304, otherwise the server returns the new resource.

Strong cache

Strong caching uses cache-control or Expires (older browsers use Expires) to have the server set an expiration time for the file, at which time it can be treated as up to date. If the time is not expired, the cached file is directly used without sending a request to the server.

Let’s look at an actual Response Headers

Common values of cache-control are as follows:

Public: Caching is available on both the server and browser

Private: Only browser-side caching

No-cache: forces the browser to submit an HTTP request to the source server for confirmation before using the cache copy. If the HTTP request is not reduced, one response body (file content) will be reduced. This option is similar to weak caching, that is, not strong caching.

Only -if-cached: indicates that the client accepts only cached responses and does not check to the original server for an updated copy.

Expiration Settings:

Max-age =60: specifies the maximum period for cache storage. After this period, the cache is regarded as expired (unit: second). This is 60 seconds

Other Settings:

No-store: The negotiated cache is used instead of the cache

Must-revalidate: The cache must verify the state of old resources before using them, and must not use expired resources.

Negotiated cache (weak cache)

Weak caches use ETag and last-modified. When the browser sends a request to the server for the first time, it returns the negotiated cache header property in the response header: ETag and last-Modified, where ETag returns a hash value and last-Modified returns the Last Modified time in GMT format.

The browser then sends a second request with the if-not-match of the ETag in the request header, which is the value of the ETag returned in the response header, and the last-modified if-modified-since. The server receives the two parameters and compares themStatus code 304, the requested resource is not modified and the browser can directly fetch data from the cache. Otherwise, the server will return status code 200 and directly return data.

Let’s look at the actual weak cache Response Headers and Request Headers

Recommended reading

  1. Strong and weak caching in the browser
  2. How to Read the HTTP cache