Cache revalidation in browser reload

Unread post by **jobbautista9** » 2024-08-10, 03:18

I noticed while observing the devtools network tab that reloading in Pale Moon behaves differently than the mainstream browsers (like Firefox). It seems like we will always revalidate our cache in plain HTTP, while in HTTPS we don't revalidate only if its a subresource and it has Cache-Control: immutable. This used to be the case in Firefox too since 49 when they added support for immutable (honoring it in HTTPS only) in bug #1267474, while Chrome ignored immutable and just only revalidates the parent resource (this is both in HTTP and HTTPS). Mozilla eventually followed Chrome's behavior in Firefox 95 (bug #1468476). While they still claim to honor immutable, this change practically made immutable obsolete for Firefox it seems.

I wonder if we should follow suit in a major release after 33.3.0. Cache strategies in the web have become different, with websites now trying to make all subresources immutable and only the parent resource needing revalidation with cache-busting (e.g. using versions or the file's hash or a UUID in filenames), so perhaps this new reload behavior would make more sense. This would eliminate a lot of revalidation we do for those who still haven't applied the immutable strategy yet and servers will only have to 304 the parent resource, which means less latency for the user.