5 ms·

Google Chrome Pages Refresh 28% Faster Because of Facebook

mrtree 10y ago
HTTP PATCH but for a GET
- ec109685 10y ago
  How is it that at all?
grepthisab 10y ago
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."
vjeux 10y ago
Here's a more indepth technical article from Facebook: https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook/ https://code.facebook.com/posts/557147474482256/this-browser...
- ctrl_freak 10y ago
  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?
crote 10y ago
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-tweak-saved-60-of-requests-to-facebook/ https://code.facebook.com/posts/557147474482256/this-browser...
Buge 10y ago
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.
- lucb1e 10y ago
  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".
  - tyingq 10y ago
    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.
klodolph 10y ago
"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.
- paulddraper 10y ago
  > "a social media company with no experience in the browser technology space" Yeah, this article is sub-par HN submission.
laurent123456 10y ago
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?
- deleted 10y ago
  [deleted]
- evmar 10y ago
  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.
  - lucb1e 10y ago
    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.
- petrosagg 10y ago
  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.
- klodolph 10y ago
  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.
xerxes777 10y ago
This is great! I mean, this was an Opera feature for 20 years, but who cares...
jongar_xyz 10y ago
OK, so this is why I have to press shift every time I reload the app I am developing! Great job.
- evmar 10y ago
  You might find my post on what "reload" actually means in Chrome interesting: http://neugierig.org/software/chromium/notes/2010/02/reload.html http://neugierig.org/software/chromium/notes/2010/02/reload.... (a bit old but the ideas are still relevant)
- Kiro 10y ago
  Keep DevTools open with "disable cache" in the network tab ticked.
  - jongar_xyz 10y ago
    Thank you for the tip.
netsharc 10y ago
HN talked about "cache-control: immutable" a few days ago, this is like the kindergarten version explanation of that. Not HN-worthy, IMO.
tyingq 10y ago
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

ec109685 10y ago
How is it that at all?

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

vjeux 10y ago

Here's a more indepth technical article from Facebook: https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook/ https://code.facebook.com/posts/557147474482256/this-browser...

ctrl_freak 10y ago
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?

crote 10y ago

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-tweak-saved-60-of-requests-to-facebook/ https://code.facebook.com/posts/557147474482256/this-browser...

Buge 10y ago

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.

lucb1e 10y ago
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".
- tyingq 10y ago
  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.

klodolph 10y ago

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

paulddraper 10y ago
> "a social media company with no experience in the browser technology space" Yeah, this article is sub-par HN submission.

laurent123456 10y ago

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?

deleted 10y ago
[deleted]
evmar 10y ago
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.
- lucb1e 10y ago
  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.
petrosagg 10y ago
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.
klodolph 10y ago
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.

xerxes777 10y ago

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

jongar_xyz 10y ago

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

evmar 10y ago
You might find my post on what "reload" actually means in Chrome interesting: http://neugierig.org/software/chromium/notes/2010/02/reload.html http://neugierig.org/software/chromium/notes/2010/02/reload.... (a bit old but the ideas are still relevant)
Kiro 10y ago
Keep DevTools open with "disable cache" in the network tab ticked.
- jongar_xyz 10y ago
  Thank you for the tip.

netsharc 10y ago

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

tyingq 10y ago

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.