Advantages of Implementing Caching in Web Applications

Utilizing cached data, rather than repeatedly fetching or computing the same information from the original source, can significantly enhance response times and overall web application performance. The key benefits include:

• Enhanced Performance: Faster loading times contribute to an improved user experience.
• Reduced Server Load: Decreased bandwidth consumption leads to cost savings and better scalability.

Common HTTP Response Status Codes Related to Cached Resources

1. 200 OK: When no cache is present or the cache is empty, the requested resource is delivered with a status of 200 OK.

2. 200 OK (from Memory Cache):

   

The resource is already stored in memory and remains fresh, so it is retrieved directly from memory. After closing and reopening the browser, this won't be seen again.

3. 200 OK (from Disk Cache):

   

The resource is retrieved from disk storage, having been cached previously. Upon reopening the page, this resource will still be accessible.

4. 304 Not Modified:

   The HTTP 304 Not Modified status indicates that the requested resources do not need to be resent, effectively redirecting to a cached version. This occurs under two scenarios:

• When the request method is safe (such as GET or HEAD)

  • When the request is conditional, using headers like If-None-Match or If-Modified-Since.

Noteworthy HTTP Headers for Caching

1. Expires: This header specifies the date and time after which the response is deemed expired. An invalid date value (0) indicates the resource is already expired. If a Cache-Control header with directives like max-age or s-maxage is present, the Expires header is disregarded.
2. Cache-Control Headers: This HTTP/1.1 header outlines caching directives for both requests and responses. Here are some frequently encountered directives:

• no-store: Instructs caches not to store the response.

  • no-cache: Requires revalidation with the server before using a cached resource.
  • max-age=<seconds>: Defines the maximum duration a resource is considered fresh relative to the request time.

3. Pragma: This HTTP/1.0 header serves as a compatibility measure for older caches, containing a single directive: no-cache.

Key Conditional Request Pairs

1. Last-Modified/If-Modified-Since:
   • Last-Modified: This header indicates the last modification date and time of a resource on the origin server, used as a validator for cached resources.
   • If-Modified-Since: This request header makes a request conditional; the server sends the resource with a 200 status only if it has been modified since the specified date.
2. Etag/If-None-Match:
   • ETag: This HTTP/1.1 response header serves as an identifier for a specific resource version, enabling efficient cache management and bandwidth savings.
   • If-None-Match: This request header makes the request conditional based on the ETag values, ensuring the server responds with the resource only if the ETag does not match.

NOTE: The client does not check if headers have changed; it simply uses them in the next request. It is the server's responsibility to decide whether to return the content or a 304 Not Modified response.

In the upcoming part, we will delve into common cache settings for various resource types and scenarios.

The first video titled "Frontend Interview Questions: Caching Function with Multiple Arguments" discusses essential caching strategies that can be pivotal during technical interviews.

The second video titled "Cached API call | Atlassian frontend interview question" explores caching mechanisms related to API calls, providing insights for prospective candidates.