5 ms·

Reload, reloaded: faster and leaner page reloads

67 points by dankohn1 10y ago

burnbabyburn 10y ago
does this have any impact on who does webdev and often substitutes resources reusing the same url or similar things?
- tyingq 10y ago
  Sounds like it will, yes. You would have to open developer tools and "disable cache" on the network tab instead.
  - deleted 10y ago
    [deleted]
- Nadya 10y ago
  Lots more Ctrl+F5 to refresh instead of just pressing F5. It's actually been super annoying to explain to Project Managers - as they often don't see CSS changes due to this change (which actually happened nearly over a month ago).
  - tokenizerrr 10y ago
    Ctrl+Shift+R is a bit more ergonomic. > It's actually been super annoying to explain to Project Managers - as they often don't see CSS changes due to this change (which actually happened nearly over a month ago). You are appending a cachebuster to the URL that changes for every release, right?
    - Nadya 10y ago
      >You are appending a cachebuster to the URL that changes for every release, right? I'm in a department with a many years outdated CMS. The modern CMS does this after minification. The version I'm stuck with doesn't do cache busting or minification. My department is stuck on the outdated CMS due to our necessary continued support of IE8. So unfortunately no, we're not. We do so manually once a site is in production but it isn't worth the effort to do manually while things are still fast moving and internal. It's much easier to occasionally remind the project manager that they need to do a hard refresh.
      - tokenizerrr 10y ago
        That sucks. If I was in your situation I'd look into having the webservers rewrite caching headers to just disable caching completely in the internal environment.
  - chias 10y ago
    My preferred solution to this is to generate links to resources like that (CSS, JS, etc) dynamically. For each filetype, set up your webserver such that `filename.[10-digits].css` is handled identically to `filename.css`. In apache, you can do this in .htaccess with a rule that looks something like: RewriteRule ^(.*)\.[\d]{10}\.(css|js|png)$ $1.$2 [L] Then generate your links by throwing the file's last modified timestamp into the URL. The net result is that if the file changes, the URL changes, and so the cache no longer applies. It's better than using a "fake" parameter (e.g. file.js?v=2) because using fake parameters suggests that the file is dynamic, causing browsers and proxies to behave differently.
  - burnbabyburn 10y ago
    exactly this, there are people that need to access testing and could have this sort of problems.
- sp332 10y ago
  If you have your cache control set correctly (short) for the resource, then the browser will still update it frequently.
tyingq 10y ago
I get the motivation, but I suspect this will end up frustrating some users. Surely moving from "reload everything" to just "reload the page only" will break some existing use cases. I suspect, for example, some people use the reload button when a captcha isn't readable, even if the captcha has a little reload button.
dfabulich 10y ago
More technical details are available in the Facebook post linked at the bottom of the article. https://code.facebook.com/posts/557147474482256 https://code.facebook.com/posts/557147474482256 > 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-speed-up-the-web/ 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.
- joekrill 10y ago
  Very unfortunate that the Chromium team decided to go this route. At least the Firefox approach leaves it in the hands of whoever is serving the content. Chromium now just makes an assumption, and completely changes existing behavior.
- 10y ago
discreditable 10y ago
So how do I "ctrl + shift + r" on mobile when I want a true reload?
- deleted 10y ago
  [deleted]
65827 10y ago
Can they do something about refreshing Gmail already? Takes forever and gmail gets hung so often I have to do it at least once a day. One of the slowest pages on the web.
nneonneo 10y ago
I still sometimes see "broken" pages (on both desktop and mobile - more common with flaky WiFi) - e.g. pages that have bad or broken CSS because the server connection was interrupted. The resulting pages are usually nigh-unusable, and the broken resources can end up cached in the browser. Usually a reload will solve this issue. It sounds like the Chrome team wanted to validate only the main resource and rely on cached data - isn't this inherently going to break the "reload a broken page" use case? It sounds as if the Chrome team wants to abandon that use case entirely because "the quality of webpages has improved". That may be true - but the quality of some network links hasn't!
- adrianN 10y ago
  When things don't work as expected I usually do a skip-the-cache reload (cmd-shift-r, ctrl-shift-r).
- benmaurer 10y ago
  This use case will still work. If your connection is interrupted the resource will not be cached. The new reload behavior will still cause the resource to be re-requested. What if the resource is corrupt -- say a bit got flipped due to a hardware error. In the old version of reload you would send a conditional request to the server "has this resource been modified since date X". The server would say "no it hasn't" with a 304 (unless the bit flip happened to affect the header and changed the date to a much newer date). Thus a normal reload would cause you to continue to use the invalid resource. The only way to fix this situation is by doing a ctrl+shift+r -- neither Chrome's nor Firefox's approach makes this worse than it was in the past
  - benjaminjackman 10y ago
    That is pretty good explantion. It seems like it's possible to kill two birds (avoiding unneeded 304s and correcting corruption) with one stone and solve this problem via something like pushing subresource integrity [1] ahead, as well as a magnet uri / IPFS notion of linking to content by it's hash. 1: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
hashhar 10y ago
I'd have to say that Firefox did this much better. https://news.ycombinator.com/item?id=13493407 https://news.ycombinator.com/item?id=13493407

67 points by dankohn1 10y ago

burnbabyburn 10y ago

does this have any impact on who does webdev and often substitutes resources reusing the same url or similar things?

tyingq 10y ago
Sounds like it will, yes. You would have to open developer tools and "disable cache" on the network tab instead.
- deleted 10y ago
  [deleted]
Nadya 10y ago
Lots more Ctrl+F5 to refresh instead of just pressing F5. It's actually been super annoying to explain to Project Managers - as they often don't see CSS changes due to this change (which actually happened nearly over a month ago).
- tokenizerrr 10y ago
  Ctrl+Shift+R is a bit more ergonomic. > It's actually been super annoying to explain to Project Managers - as they often don't see CSS changes due to this change (which actually happened nearly over a month ago). You are appending a cachebuster to the URL that changes for every release, right?
  - Nadya 10y ago
    >You are appending a cachebuster to the URL that changes for every release, right? I'm in a department with a many years outdated CMS. The modern CMS does this after minification. The version I'm stuck with doesn't do cache busting or minification. My department is stuck on the outdated CMS due to our necessary continued support of IE8. So unfortunately no, we're not. We do so manually once a site is in production but it isn't worth the effort to do manually while things are still fast moving and internal. It's much easier to occasionally remind the project manager that they need to do a hard refresh.
    - tokenizerrr 10y ago
      That sucks. If I was in your situation I'd look into having the webservers rewrite caching headers to just disable caching completely in the internal environment.
- chias 10y ago
  My preferred solution to this is to generate links to resources like that (CSS, JS, etc) dynamically. For each filetype, set up your webserver such that `filename.[10-digits].css` is handled identically to `filename.css`. In apache, you can do this in .htaccess with a rule that looks something like: RewriteRule ^(.*)\.[\d]{10}\.(css|js|png)$ $1.$2 [L] Then generate your links by throwing the file's last modified timestamp into the URL. The net result is that if the file changes, the URL changes, and so the cache no longer applies. It's better than using a "fake" parameter (e.g. file.js?v=2) because using fake parameters suggests that the file is dynamic, causing browsers and proxies to behave differently.
- burnbabyburn 10y ago
  exactly this, there are people that need to access testing and could have this sort of problems.
sp332 10y ago
If you have your cache control set correctly (short) for the resource, then the browser will still update it frequently.

tyingq 10y ago

I get the motivation, but I suspect this will end up frustrating some users. Surely moving from "reload everything" to just "reload the page only" will break some existing use cases. I suspect, for example, some people use the reload button when a captcha isn't readable, even if the captcha has a little reload button.

dfabulich 10y ago

More technical details are available in the Facebook post linked at the bottom of the article. https://code.facebook.com/posts/557147474482256 https://code.facebook.com/posts/557147474482256 > 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-speed-up-the-web/ 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.

joekrill 10y ago
Very unfortunate that the Chromium team decided to go this route. At least the Firefox approach leaves it in the hands of whoever is serving the content. Chromium now just makes an assumption, and completely changes existing behavior.
10y ago

discreditable 10y ago

So how do I "ctrl + shift + r" on mobile when I want a true reload?

deleted 10y ago
[deleted]

65827 10y ago

Can they do something about refreshing Gmail already? Takes forever and gmail gets hung so often I have to do it at least once a day. One of the slowest pages on the web.

nneonneo 10y ago

I still sometimes see "broken" pages (on both desktop and mobile - more common with flaky WiFi) - e.g. pages that have bad or broken CSS because the server connection was interrupted. The resulting pages are usually nigh-unusable, and the broken resources can end up cached in the browser. Usually a reload will solve this issue. It sounds like the Chrome team wanted to validate only the main resource and rely on cached data - isn't this inherently going to break the "reload a broken page" use case? It sounds as if the Chrome team wants to abandon that use case entirely because "the quality of webpages has improved". That may be true - but the quality of some network links hasn't!

adrianN 10y ago
When things don't work as expected I usually do a skip-the-cache reload (cmd-shift-r, ctrl-shift-r).
benmaurer 10y ago
This use case will still work. If your connection is interrupted the resource will not be cached. The new reload behavior will still cause the resource to be re-requested. What if the resource is corrupt -- say a bit got flipped due to a hardware error. In the old version of reload you would send a conditional request to the server "has this resource been modified since date X". The server would say "no it hasn't" with a 304 (unless the bit flip happened to affect the header and changed the date to a much newer date). Thus a normal reload would cause you to continue to use the invalid resource. The only way to fix this situation is by doing a ctrl+shift+r -- neither Chrome's nor Firefox's approach makes this worse than it was in the past
- benjaminjackman 10y ago
  That is pretty good explantion. It seems like it's possible to kill two birds (avoiding unneeded 304s and correcting corruption) with one stone and solve this problem via something like pushing subresource integrity [1] ahead, as well as a magnet uri / IPFS notion of linking to content by it's hash. 1: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

hashhar 10y ago

I'd have to say that Firefox did this much better. https://news.ycombinator.com/item?id=13493407 https://news.ycombinator.com/item?id=13493407