Google Chrome Pages Refresh 28% Faster Because of Facebook | Hacker News Reader

Google Chrome Pages Refresh 28% Faster Because of Facebook

1reddrop.com

The original source[0] contains the technical background anyone here is probably looking for.

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...

"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.

> "a social media company with no experience in the browser technology space"

Yeah, this article is sub-par HN submission.

HN talked about "cache-control: immutable" a few days ago, this is like the kindergarten version explanation of that. Not HN-worthy, IMO.

Here's a more indepth technical article from Facebook: https://code.facebook.com/posts/557147474482256/this-browser...

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 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."

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.

Yes, and it also had to work (long ago) with poorly-written, non-standards-compliant HTTP proxies.

This is great! I mean, this was an Opera feature for 20 years, but who cares...

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.

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.

HTTP PATCH but for a GET

How is it that at all?

OK, so this is why I have to press shift every time I reload the app I am developing! Great job.

You might find my post on what "reload" actually means in Chrome interesting: http://neugierig.org/software/chromium/notes/2010/02/reload.... (a bit old but the ideas are still relevant)

Keep DevTools open with "disable cache" in the network tab ticked.

Thank you for the tip.

Reply on news.ycombinator.com