Search code examples
google-chromehttpcachingbrowser-cachecache-control

Why does the browser force revalidation when serving an initial document request?

I do understand how Cache-Control header works. However, I noticed that the browser treats the document request differently from other requests. The document request here is the first request that the browser makes when the user types the domain on the address bar and hits enter.

I tested an HTML page with the response header as follows:

Cache-Control: public, max-age=31536000, immutable

The header tells that the browser should cache the response for 1 year. But in the case document request, both Chrome and Firefox will revalidate it anyway. The evidence for it is the 304 response status.

enter image description here

Here is the test URL: https://test-http-cache-2exijs7pxj7x.runkit.sh/

I can not find an official document for this behavior. So it would be nice if someone could explain how the browser caches the document request and refers to an official document.

Thanks in advance!

Edit

The outcome mentioned above is the result of a soft reload (when the user hits the reload button or re-enters the same address). For navigation requests, the browser respects the Cache-Control and serves the response from the cache

Solution

  • According to the spec, the immutable extension to the Cache-Control header:

    Clients SHOULD NOT issue a conditional request during the response’s freshness lifetime (e.g., upon a reload) unless explicitly overridden by the user (e.g., a force reload).

    The immutable extension only applies during the freshness lifetime of the stored response. Stale responses SHOULD be revalidated as they normally would be in the absence of the immutable extension.

    The freshness of a response is determined by its age, which in HTTP is the time elapsed since the response was generated. You can read more about how a cache calculates the age on MDN, but it is essentially the difference between when the object was stored by the cache and it's max-age (or the value of an Expires header), which in your case is one year, so any cache following the spec, should not attempt a conditional request to validate the stored object.

    I have confirmed on my Ubuntu laptop using Chrome and Firefox that Firefox will not issue a conditional validation request upon caching the response, but Chrome will. If you inspect the Browser compatibility table on MDN for the Cache-Control header, you will see that Chrome does not support the immutable extension, but Firefox does.

    In short, according to the spec, clients should not issue a conditional request to validate a cached object that included the immutable extension to a response's Cache-Control header while the object is still fresh.

    Chrome is not honoring the immutable extension, and therefore issuing a conditional request in the form of an If-None-Match request header due to the Etag on the returned resource.

    Addendum:

    The comments to this answer add an additional question not readily apparent in the original question. Namely, why is Chrome validating a cached resource that is fresh when a user reloads the page, but not during navigation?

    Chrome has decided to not support immutable because they seem to feel their heuristic at handling reloads is sufficient and not worth the overhead of supporting another extension to Cache-Control with little observed value. It has been available to work on for years, but nobody has bothered.

    In short, their heuristic will only validate a cached top level resource on reloads (which real end users really don't do), and use the cache for sub-resources. You can read about how Chrome revamped their heuristic in this article: https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html

    Note, the test URL provided in the question does not have any sub-resouces. Not only that, it appears to be serving plain text as text/html where text/plain might be more appropriate.