<h2 id="content"><a href="#content" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Content</h2>
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#cache-control-headers">Cache Control Headers</a></li>
<li><a href="#validation">Validation</a>
<ul>
<li><a href="#etag">ETag</a></li>
<li><a href="#validation-request">Validation Request</a></li>
<li><a href="#the-validation-request-outcomes">Validation Request outcomes</a></li>
</ul>
</li>
<li><a href="#vary">Vary</a></li>
<li><a href="#request-collapsing">Request Collapsing</a></li>
<li><a href="#response-staleness">Response Staleness</a>
<ol>
<li><a href="#1-serve-stale-while-revalidate">Serve Stale, while revalidate</a></li>
<li><a href="#2-revalidate-before-reuse">Revalidate before reuse</a></li>
</ol>
</li>
<li><a href="#deleting-from-the-cache">Deleting From The Cache</a></li>
<li><a href="#conclusion">Conclusion</a></li>
</ul>
<h2 id="introduction"><a href="#introduction" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Introduction</h2>
<p>HTTP caching is a standard that many software tools follow and are built on.</p>
<p>The tools include browsers, content delivery networks (CDNs), proxy caches, gateways and many more.</p>
<p>So, that means these tools either support it or are at least compatiable with it because it is so widely used.</p>
<p><strong>This is why it is important to understand it because so many tools are built on this caching standard.</strong></p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-tools-built-on-it.png" alt="HTTP caching tools built on it" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>Illustration of common software tools built on the HTTP caching standard</i></blockquote>
  </div>
</div>
<p>After going through this guide, you should have a better understanding of how HTTP caching works!</p>
<p>It’s going to save you hours of reading and researching!</p>
<p>There are many details that you can learn about HTTP caching but of all of them, I think these 6 concepts would give you enough to build a solid foundation.</p>
<p>It would be like learning the 80/20 of HTTP caching!</p>
<p><strong>Here are the 6 concepts:</strong></p>
<ol>
<li>
<p>Cache-Control headers</p>
</li>
<li>
<p>Validation</p>
</li>
<li>
<p>Vary</p>
</li>
<li>
<p>Request Collapsing</p>
</li>
<li>
<p>Response Staleness</p>
</li>
<li>
<p>Deleting from the cache</p>
</li>
</ol>
<p>Let’s dive right in!</p>
<h2 id="cache-control-headers"><a href="#cache-control-headers" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Cache Control headers</h2>
<p>Cache control header provides a way for the server to give instructions to the client or the shared cache about the caching behaviour for a particular resource.</p>
<p><strong>Here is an example:</strong></p>
<div class="remark-highlight"><pre class="language-http"><code><span class="token header-name keyword">Cache-Control:</span> max-age=3600 // 60 minutes 
</code></pre></div>
<p><code class="language-">max-age
</code> is one of the most common directives to use. It controls caching which allows us to specify how long to cache a particular response.</p>
<p>This is not the only directive, there are several other types that you can use.</p>
<p><strong>Here are some of the more common types:</strong></p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-common-cache-control-headers.png" alt="HTTP caching common Cache-Control directives" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>Common <code>Cache-Control</code> directives</i></blockquote>
  </div>
</div>
<p>For a full list of directives, check out <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control" target="_blank" rel="nofollow noopener noreferrer">MDN - Cache Control</a>.</p>
<blockquote class="common">
<b>💡 Tip:</b> You can also add several directives by separating them with a comma.
<p><b>Here is an example: </b> <code class="language-">Cache-Control: public, max-age=3600
</code></p>
</blockquote>
<h2 id="validation"><a href="#validation" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Validation</h2>
<p>Of all the concepts, this is probably the most important, and that concept has to do with validation.</p>
<p>When a resource in a cache becomes stale, the cache does not immediately remove it.</p>
<p>Rather it “validates” this resource with the server by making a request with the <code class="language-">If-None-Match
</code> header and the <code class="language-">ETag
</code> value.</p>
<p>In a Later section, we’ll also discuss the different strategies for handling stale responses.</p>
<h3 id="etag"><a href="#etag" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>ETag</h3>
<p>ETags are typically a checksum (it can be a hash or a version number) generated by the server to check whether or not a resources has changed.</p>
<p>Let’s see how this fits in with the validation request.</p>
<h3 id="validation-request"><a href="#validation-request" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Validation request</h3>
<p>To perform a validation for a cached response, the client sends a <code class="language-">GET
</code> request to the server with the appropriate details in the request including the <code class="language-">If-None-Match
</code> header with the <code class="language-">ETag
</code> as the value.</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-talking-to-the-server.png" alt="Talking to the server" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>Illustration of a validation request: client validating a response with server</i></blockquote>
  </div>
</div>
<p>The response of this request has two outcomes.</p>
<h3 id="the-validation-request-outcomes"><a href="#the-validation-request-outcomes" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>The validation request outcomes</h3>
<p>There are only two outcomes from the validation request.</p>
<ol>
<li>
<p><strong>Resource is not modified</strong> - The server responds with a HTTP <code class="language-">304 Modified
</code>, the response remains the same</p>
</li>
<li>
<p><strong>New resource is available</strong> - The server responds with a HTTP <code class="language-">200 OK
</code>, and returns the latest version of the response</p>
</li>
</ol>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-validation-request-outcomes.png" alt="Validation request outcomes" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>Illustration of the possible outcomes</i></blockquote>
  </div>
</div>
<p>Now, what happens if we have variations of the resource but the same URL.</p>
<p>How do we go about caching that ? That’s where the <code class="language-">Vary
</code> header comes in.</p>
<h2 id="vary"><a href="#vary" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Vary</h2>
<p>When a response comes back from the server, it is typically cached based on its URL.</p>
<p>However, there are times when the same URL can produce many variations (ie languages, compression formats).</p>
<p><strong>Some examples include:</strong></p>
<ul>
<li>
<p><code class="language-">Accept-Language
</code> - A different language or localization</p>
</li>
<li>
<p><code class="language-">Content-Encoding
</code> - type of compression used for transferring between the client &#x26; origin server</p>
</li>
</ul>
<p>So, what we can do in this scenario is to provide a <code class="language-">Vary
</code> header in the response from the server to alter the cache key.</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-vary.png" alt="HTTP caching using Vary with Accept-Language header" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><b> Example: </b><i>Caching when using <code>Accept-Language</code> for the <code> Vary</code> header</i></blockquote>
  </div>
</div>
<p>With the <code class="language-">Vary
</code> header, you are not limited to just one header.</p>
<p>You can provide one or many of them in a comma separated format (ie <code class="language-">Vary: Accept-Language,Content-Encoding
</code>), those values will be used to create the cache key for storing the cached response.</p>
<h2 id="request-collapsing"><a href="#request-collapsing" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Request collapsing</h2>
<p>Another concept to understand in regards to HTTP caching, is this idea of request collapsing.</p>
<p>When there is a shared cache, and multiple clients are requesting for the same resource, it would reduce the number of forwarded requests to the origin server by collapsing it.</p>
<p>Let’s go through an example.</p>
<p>When a request comes in for a resource, and assuming a response is not in the cache, the shared cache would forward the request to the origin server.</p>
<p>During this time, let’s say more requests arrive for the same resource.</p>
<p>In this case, the shared cache would not forward any more requests to the server, rather it would wait for the first request.</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-request-collapsing-initial.png" alt="HTTP caching request collapsing" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>Illustration of the request collapsing from multiple clients</i></blockquote>
  </div>
</div>
<p>Then when the request returns, it can use the same response to serve multiple clients who requested the same resource.</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-request-shared-response.png " alt="HTTP caching request collapsing shared response" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>Illustration of shared response to serve multiple clients</i></blockquote>
  </div>
</div>
<blockquote class="common">  
<p><b>⚠️ Important: </b> The important thing to note here is that this only applies to responses that can be shared across the clients.</p>
</blockquote> 
<h2 id="response-staleness"><a href="#response-staleness" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Response Staleness</h2>
<p>When working with cached responses, it is also important to talk about how to handle situations when they become stale.</p>
<p>There are two common directives available that can be used to manage responses that have expired.</p>
<p>The strategy you choose to use will depend on the type of resource you are serving, and the experience you wish to provide.</p>
<p><strong>The Two options are:</strong></p>
<ol>
<li>
<p>Serve stale, while revalidate</p>
</li>
<li>
<p>Revalidate before reuse</p>
</li>
</ol>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-managing-stale-responses.png" alt="HTTP caching managing stale responses" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>Illustration of the different options to managing stale responses</i></blockquote>
  </div>
</div>
<p>Let’s go through these options.</p>
<h4 id="1-serve-stale-while-revalidate"><a href="#1-serve-stale-while-revalidate" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>1. Serve stale, while revalidate</h4>
<p>When the response expires, this option would serve the stale response. Then it would revalidate with the server in the background.</p>
<p>This means that some clients will temporarily get a stale responses while the cache revalidates in the background. Just keep this in mind.</p>
<p>In some cases, you may want to always serve the latest response. So, this may or may not work depending on your use case.</p>
<h4 id="2-revalidate-before-reuse"><a href="#2-revalidate-before-reuse" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>2. Revalidate before reuse</h4>
<p>When the response expires, this option will revalidate with the server before reusing a response.</p>
<p>If the response has changed, the server will return with the new response, which will be served to the client.</p>
<p>This means that the cache will revalidate immediately before serving a response to check if the current response is still up-to-date.</p>
<p>After doing so, it will either serve the existing response (if it hasn’t changed) or the new response to the client.</p>
<p>There is also <code class="language-">Cache-Control: proxy-revalidate
</code> which is identical to <code class="language-">must-revalidate
</code> but it is used by shared caches.</p>
<h4 id="what-happens-if-the-validation-request-fails-"><a href="#what-happens-if-the-validation-request-fails-" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>What happens if the validation request fails ?</h4>
<p>This is not directly related to stale responses but since we are discussing the validation request, it may be worth mentioning.</p>
<p>Upon receiving an error response from the origin server, the default behaviour of the shared cache varies.</p>
<p><em>Most</em> shared caches will try serve the stale response (if applicable) — Please keep in mind that this is not always the case.</p>
<p>If you want to support this behaviour, you can use the <code class="language-">Cache-Control: stale-if-error=[time-in-seconds]
</code> directive.</p>
<p><strong>This translates to:</strong> If the shared cache receives an error response then serve the stale response for the defined duration.</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-stale-if-error.png" alt="HTTP caching using stale-if-error directive" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>Illustration of using <b>stale-if-error</b> directive</i></blockquote>
  </div>
</div>
<p>Ok we talked about managing stale responses but what about the cached responses that are no longer valid ?</p>
<h2 id="deleting-from-the-cache"><a href="#deleting-from-the-cache" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Deleting from the cache</h2>
<p>Sometimes you may want to remove a stored response from the cache.</p>
<p>when working with a client or a shared cache, there are differences in how this is handled.</p>
<h3 id="client-caches-browser-cache"><a href="#client-caches-browser-cache" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Client caches (Browser Cache)</h3>
<p>When working with client cache (browser cache), there isn’t a direct way to delete responses from the cache after caching it.</p>
<p>That means, you would have to wait until the cached response expires before it can be changed.</p>
<p>There are proposals for a new HTTP header, <code class="language-">Clear-Site-Data: cache
</code>, which can be set to clear the cache in the browser.</p>
<p>However, this may not supported on all browsers, so just keep that in mind!</p>
<h3 id="shared-caches"><a href="#shared-caches" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Shared caches</h3>
<p>When working with a shared cache, you typically have more control over the items in the cache (if it is a self managed service).</p>
<p>Most shared caches (ie CDNs, proxy caches, gateways) will provide be an API to delete (or invalidate) the items in the cache.</p>
<p>Ultimately, this means when storing responses in the client (browser cache), there will be less control.</p>
<p>When devising a caching strategy, you should take that into consideration.</p>
<h2 id="conclusion"><a href="#conclusion" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Conclusion</h2>
<p>Like I mentioned in the introduction, this guide is not meant to be a guide that covers everything.</p>
<p>Rather it covers some of major elements (The 6 core concepts) to HTTP caching that would help you to better understand how it works.</p>
<p>Once you understand these elements, it should be just a matter of looking up the other details to fill in the gaps.</p>
<p>Let’s do a recap.</p>
<p><strong>The Takeaways:</strong></p>
<blockquote class="common">
<ul>
<li>
<p><strong>Cache-Control headers</strong> - This is the HTTP header that controls the caching behaviour, and you do so via directives</p>
</li>
<li>
<p><strong>Validation</strong> - When a cached response goes stale, validation is when the cache reaches out to the server to confirm whether or not this response is up-to-date ⭐️</p>
</li>
<li>
<p><strong>Vary</strong> - When working with variations of the response from the same URL, you can adjust the cache key based on other properties by using the <code class="language-">Vary
</code> header</p>
</li>
<li>
<p><strong>Request Collapsing</strong> - When multiple clients request the same resource, the shared cache will combine the forwarded request into one then return the same server response to all the clients (assuming this is a shared response)</p>
</li>
<li>
<p><strong>Response staleness</strong> - There are two common strategies for managing stale responses</p>
<ol>
<li>
<p><code class="language-">stale-while-revalidate
</code> - Serve the stale response while the cache revalidates in the background</p>
</li>
<li>
<p><code class="language-">must-revalidate
</code> (or <code class="language-">proxy-revalidate
</code> for shared cache) - The cache must revalidate with server before serving the response</p>
</li>
</ol>
</li>
<li>
<p><strong>Deleting from the cache</strong> - Keep in mind that if you are caching responses using browser cache, there isn’t an easy way to invalidate or delete the cached responses</p>
</li>
</ul>
</blockquote>
<p>That’s it! I hope this guide was helpful.</p>
<p>If you’d like to keep learning about HTTP caching, here are a few more resources I recommend:</p>
<ul>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching" target="_blank" rel="nofollow noopener noreferrer">MDN - HTTP Caching</a></li>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control" target="_blank" rel="nofollow noopener noreferrer">MDN - HTTP Cache-Control header</a></li>
<li><a href="https://web.dev/http-cache/" target="_blank" rel="nofollow noopener noreferrer">Prevent unnecessary network requests with the HTTP Cache</a></li>
<li><a href="https://www.mnot.net/cache_docs/" target="_blank" rel="nofollow noopener noreferrer">Caching Tutorial for Web Authors and Webmasters</a></li>
<li><a href="https://httpwg.org/specs/rfc9111.html" target="_blank" rel="nofollow noopener noreferrer">HTTP Caching RFC 9111</a></li>
<li><a href="https://www.ietf.org/rfc/rfc2616.txt" target="_blank" rel="nofollow noopener noreferrer">HTTP/1.1 RFC 2616</a></li>
</ul>
<p>If you found this helpful or learned something new, please share this article with a friend or co-worker 🙏🧡 (Thanks!)</p>


Jerry Chang

Go Back

HTTP caching: The 6 Core Concepts

Enjoy the content ?