Http caching mechanism as an important means of web performance optimization, for students engaged in Web development, should be a basic link in the knowledge base, but also for students who want to become front-end architects is a necessary knowledge and skills. For many of you on the front end, it’s not always clear that the browser caches the requested static file, but why it’s cached and how it works. Here, I will try to use a simple and clear text, like you introduce the HTTP cache mechanism, expect to understand the right front-end cache to help.

Using caching has several benefits:

  • Caching reduces redundant data transfers and saves you money on your network.
  • Caching relieves network bottlenecks. Pages load faster without requiring more bandwidth.
  • Caching reduces the requirements on the original server. The server can respond more quickly and avoid overloads.
  • Caching reduces distance latency because it is slower to load pages from farther away.

Before introducing HTTP caching, let’s take a quick look at HTTP packets

HTTP packets are data blocks sent and responded to during communication between the browser and the server. The browser requests data from the server and sends a request message. The server returns data to the browser and sends a response message. The packet information is divided into two parts

  • Contains attributes first (header) — — — — — — — — — — — — — — — — — — — — — — — — — – additional information (such as cookies, cache information) rules related to cache information, are included in the header
  • Contains data (the body) in the main body of — — — — — — — — — — — — — — — — — — — — — — — HTTP request really want a part of the transmission

HTTP caches have a variety of rules, and they are categorized by whether or not a request needs to be redirected to the server. I’ve divided them into two main categories (mandatory cache, negotiated cache)

Mandatory cache:

The overall process of forced caching is relatively simple, that is, after the first access to the server to fetch data, it will not be repeated within the expiration period. At the heart of implementing this process is knowing if the current time has exceeded the expiration date.

The HTTP 1.0

In HTTP 1.0, caching is enforced through the Expires response header. Expires indicates a future time when a resource will expire. That is, when a request expires, the resource cache expires and a request is sent to the server to retrieve the resource. If a request is made within the expires time limit, the browser directly reads the information in the local cache database, either randomly based on the browser’s policy.

The HTTP 1.1

In HTTP 1.1, mandatory caching is implemented through cache-control response headers. Cache-control has multiple values:

  • Private: The client can cache
  • Public: both client and proxy servers can cache.
  • Max-age = XXX: the cached resource will expire in XXX seconds.
  • No-cache: a negotiated cache is used to verify expiration.
  • No-store: not cacheable (rarely used)

The most commonly used field is max-age= XXX, indicating that cached resources will expire in XXX seconds. In general, both versions of the mandatory cache are implemented for compatibility. The most commonly used field is max-age= XXX, indicating that cached resources will expire in XXX seconds. In general, both versions of the mandatory cache are implemented for compatibility.

Negotiation cache:

The first time the browser requests data, the server returns the cache id along with the data to the client, which backs up both to the cache database. When requesting data again, the client sends the backup cache ID to the server. The server checks the backup cache ID. After the check succeeds, the server returns the 304 status code to inform the client that the backup data is available

  • Last-Modified / If-Modified-Since

This field notifies the server when the resource returned by the server was last modified during the last request. When the server receives the request, it finds the if-modified-since header and compares it with the last modification time of the requested resource. If the last modification time of a resource is greater than if-modified-since, it indicates that the resource has been Modified again. The status code 200 is returned in response to the entire resource content. If the last modification time of a resource is less than or equal to if-modified-since, the resource has not been Modified, the browser responds to HTTP 304, telling the browser to continue using the saved cache.

  • Etag/ if-none-match (priority higher than last-modified/if-modified-since)

Etag: A unique identifier that tells the browser that the current resource is on the server when the server responds to a request (the generation rule is determined by the server).

If-none-match: this field is used to notify the server of the unique identifier of cached data in the client segment when the server is requested again. After receiving the request, the server finds if-none-match header and compares it with the unique identifier of the requested resource. If the header is different, it indicates that the resource has been changed again. In this case, the server responds to the entire resource content and returns the status code 200. If yes, the resource has not been modified. In this case, the browser responds to HTTP 304, telling the browser to continue using the saved cache.