HTTP caching: how the site reuses data already received

Useful to know

When we open a web page, the browser receives documents, images, and other resources. Some of these responses can be saved and used on a subsequent visit. This is the basic idea of HTTP caching. Instead of the same file being transferred multiple times, the appropriate copy serves the next request. The benefit is less data transferred, and in certain scenarios less work for the server. However, the cache needs rules when the copy remains appropriate. [1]

There is a substantial difference between the browser's private cache and the shared cache in front of the site. The first serves the particular client. The second, for example, managed cache in CDN, can return a saved response to various visitors. This is convenient for commonly available images and identical pages, but requires attention when it comes to user profile content. One address does not necessarily mean the same response for all people. The mere presence of a cookie is also not a sufficient privacy policy. [1]

The Cache-Control header describes an important part of the behavior. The max-age directive sets a period of freshness in seconds. In private, the response is intended for personal cache, not shared storage. Especially easy to confuse no-cache and no-store: the first allows preservation, but requires verification before reuse; the second prohibits storing the specific response. Therefore, the inscription no-cache does not automatically mean that the browser does not have any saved copy. [2]

Revalidation can transfer far less data than downloading the resource again. The server sends a ETag - resource version identifier. Upon next conditional request, the client returns this identifier through If-None-Match. If the representation has not changed, the server can respond with 304 Not Modified without a body. The client then uses the content already available. If the version is different, it should receive the new resource. ETag is not necessarily a checksum; the specific mode of generation is determined by the server. [3]

Consider a hypothetical example with a generally available illustration to an article. If it does not change, re-sending the same bytes at each opening has no editing value. However, when the designer replaces it, the old copy may already show the wrong scheme. One practical approach is for the new version to receive a different address, for example a file name with a version. Thus, the old and the new image also differ for the cache, and the document can explicitly indicate the desired one. [2]

To understand the actual behavior, we need to distinguish three situations: using a fresh local copy, checking a saved version, and downloading the entire response. They may look the same to the reader, but lead to different network traffic. The 304 response still means communication with the server; it does not amount to a lack of request. Therefore, when evaluating acceleration, it is useful to look at both the response code and the data transferred. [1, 3]