> we found that Chrome would revalidate all resources on pages that were loaded from making a POST request. The Chrome team told us the rationale for this was that POST requests tend to be pages that make a change — like making a purchase or sending an email — and that the user would want to have the most up-to-date page. However, sites like Facebook use POST requests as part of our login process. Every time a user logged in to Facebook the browser ignored its cache and revalidated all the previously downloaded resources. We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.
And later on, discussing immutable long-cached resources:
> There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones. You can read more about their process here [the parent article]. Because of Chrome's blanket approach, all developers and sites are able to see improvement without making any changes themselves.
They say Firefox resolved not to implement it this way, instead adding a new cache-control header, "immutable." https://hacks.mozilla.org/2017/01/using-immutable-caching-to...
So, uh, this means that Chrome and Firefox now have very different caching behavior, by design. :-(
I must say that I prefer Firefox's approach, or even FB's approach where long-lived cache results are handled differently. Refresh's revalidation behavior provides a valuable safety net to ensure that users know how to get a page "back to normal."
Regardless, I wish the Chrome and Firefox team would come to agreement on a proposal, rather than each doing their own thing. That's bad for the web.