I thought this would be a much more technical article, but it basically boiled down to Facebook suggesting to Chrome that Chrome not reload static things.
"Technically, when you refresh a browser page, it is counted as the next visit to that page. What Facebook did was to suggest that Chrome and Firefox only revalidate the main resource, or the page itself, rather than images, scripts and other resources."
The original post should be updated to point to this link.
Interesting read. Also seems like a subtle jab at Microsoft and Apple when they said, "We're happy to have such a good working relationship with our friends on the Chrome and Firefox teams." Conditional requests were actually higher on IE and Safari than Firefox, so chances are they tried to engage with those teams but were shut down?
I guess it depends on what the definition of refresh is. What do I want the button to do when I press it, as a user? I guess only refreshing the main html, and not cached resources is an OK design, as long as shift+refresh still refreshes everything.
That question is kind of irrelevant. The immutable header is set on items that will never ever ever change. If you expect those to get updated with a ctrl+f5 or something, you shouldn't be setting the immutable header for that item.
The only times I can imagine you want to refresh immutable items anyway is when debugging the network: when your download was corrupted, to watch page timings in the developer console, or when watching the traffic flow in wireshark or something. In those cases I guess there should be a developer option, but you specifically talked about "as a user".
It isn't just the immutable header though. Chrome is changing existing behavior for resources that do not have that header. AFAICT, Firefox is the only browser with current plans for immutable.
"a social media company with no experience in the browser technology space"
I don't think anyone believes that Facebook has anything short of a huge breadth of software development expertise, manpower, and initiative.
On a personal note, I'm quite happy about cache-control: immutable. All my personal web projects embed content hashes in URIs for static resources (except those with published URIs). This makes things a little simpler.
I still don't really get what's so special about "cache-control: immutable". Isn't it the same as setting the cache expiration date to something like in a year or two? Why is a special property needed for this?
When you hit the reload button, the browsers would still revalidate resources with long expiration dates. The fixes in the Facebook post are that Chrome changed to no longer do this on any subresource, and Firefox changed to no longer do this on cache-control: immutable resources.
I thought this was possible... that explains my frustration with "why won't the damn thing not revalidate" when I last tried it (I think that was a few years ago by now).
Weird though, it seems so obvious and I thought something like no-revalidate existed. I guess I'm confusing no-cache and must-revalidate.
The problem is that when a user refreshes the page using the reload button the browser will revalidate even cached resources. This results in a lot of requests that get carry the `If-Modified-Since` header and 304 responses. Cache-Control: immutable avoids this revalidation altogether since it's guaranteed that the source won't ever change.
The problem is that browsers didn't do the right thing, and now they can't do the right thing because web developers relied on actual browser behavior rather than idealized spec-compliant behavior. If you've heard that story before, it's because a dozen other minor warts (especially regarding HTTP headers) appeared for the exact same reason.
Well... kinda. I'd say this is the result of a mismatch between "refresh everything, anything could have changed" and what most people actually want when refreshing, which is "check for new content".
"cache-control: immutable" at least lets servers declare a contract that pushes those two closer towards each other, and it also works perfectly for those cache-busting resource-version-params, which browsers haven't been able to trust. Which is probably why Chrome had that POST-invalidation thing - there are a lot of flawed cache headers out there, and users don't care that you're following the spec when things break.
I predict quite a bit of scattered chaos when these changes roll out. Mobile will be especially fun for help desks, as there is no obvious way to do shift-f5 for a hard reload.
26 comments
[ 5.3 ms ] story [ 113 ms ] thread"Technically, when you refresh a browser page, it is counted as the next visit to that page. What Facebook did was to suggest that Chrome and Firefox only revalidate the main resource, or the page itself, rather than images, scripts and other resources."
Interesting read. Also seems like a subtle jab at Microsoft and Apple when they said, "We're happy to have such a good working relationship with our friends on the Chrome and Firefox teams." Conditional requests were actually higher on IE and Safari than Firefox, so chances are they tried to engage with those teams but were shut down?
TL;DR:
- Chrome needlessly revalidated all resources after a POST request
- Firefox gets a "cache-control: immutable" header to indicate that a resource will never change and thus doesn't need to be revalidated.
[0]: https://code.facebook.com/posts/557147474482256/this-browser...
The only times I can imagine you want to refresh immutable items anyway is when debugging the network: when your download was corrupted, to watch page timings in the developer console, or when watching the traffic flow in wireshark or something. In those cases I guess there should be a developer option, but you specifically talked about "as a user".
I don't think anyone believes that Facebook has anything short of a huge breadth of software development expertise, manpower, and initiative.
On a personal note, I'm quite happy about cache-control: immutable. All my personal web projects embed content hashes in URIs for static resources (except those with published URIs). This makes things a little simpler.
Yeah, this article is sub-par HN submission.
Weird though, it seems so obvious and I thought something like no-revalidate existed. I guess I'm confusing no-cache and must-revalidate.
"cache-control: immutable" at least lets servers declare a contract that pushes those two closer towards each other, and it also works perfectly for those cache-busting resource-version-params, which browsers haven't been able to trust. Which is probably why Chrome had that POST-invalidation thing - there are a lot of flawed cache headers out there, and users don't care that you're following the spec when things break.