location.reload() can take the same behavior with that we are enabling on m54 for reloads by user actions?

[Takashi Toyoshima]

Hi loading-dev,

Now Chrome is enabling new reload behavior for user action initiated reloads, pull-to-refresh, reload button, reload from menu, etc. On mobiles, we already have new reload on current stable channel for pull-to-refresh, and we will have this even on desktops at the next stable 54. But my question is "is it reasonable to change location.reload() behavior in the same way?". This question comes from a local mail thread, but I'd start a public thread to discuss this.

New reload (faster reload)

 - forces to revalidate main resource, and follows the protocol for other sub-resources.

Traditional reload

 - forces to revalidate all resources.

Then, as a next step, we probably want to make location.reload() to take the same behavior. Actually, there are multiple ways to reload a page in JavaScript, and each have minor differences.

location.reload()

 - Take a traditional reload behavior

location.reload(boolean) - non-standard, supported by Firefox

 - Take a traditional reload if the boolean argument is false. Otherwise it reloads without using cache, aka shift-reload equivalent.

location.href = location.href

 - Follows the protocol for all resources. Unfortunately, this is also different from aka same page navigation. Chrome takes a behavior as doing a different page navigation.

Relevant spec: https://html.spec.whatwg.org/multipage/browsers.html#dom-location-reload

 - Today, the spec for location.reload() does not say anything about cache behavior, and does not take a boolean argument.

Changing location.reload() behavior won't violate the spec, but I don't have clear confidence if this does not break web compatibility in the wild. Probably, I can change this behavior under a field trial, but I want to hear some feedback before changing it.

Also, I'd note that Chrome does not apply reload behavior for resources that are requested after onload event. This aims not to apply reload operation forever in single page applications. This may make cache control a little difficult for web developers.

--

Takashi Toyoshima
Software Engineer, Google

[Ojan Vafai]

IMO, we should be aiming to have exactly two kinds of reload on the web. One that uses the cache and one that doesn't.

The ideal end result would be that

1. Uses the cache and forcibly revalidates only the main resource:
   
1. reload button
2. f5/cmd+r
3. location.reload
4. location.href = location.href
2. Doesn't use the cache
1. location.reload(bool)
2. shift+refresh

I suspect that if you polled developers today, 99/100 would expect this to already be the case. Also, that seems like the most predictable behavior for web developers and it happens to also be the fastest if we make them all match the new reload behavior. Nit: location.href=location.href might be slower because it needs to revalidate the main resource.

+Rick Byers +Dru Knox since there's a predictability component to this.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

[Chris Bentzel]

Arguably we could do something like two finger scrolldown for force-reload on mobile as well but there might be complications. Similarly, if time between refreshes fast might shift-reload.

But I do like the general framing of the two reload cases and that is the way things are going.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

[Ben Maurer]

Should hitting enter on the url bar (ie, navigating to the URL you are already on) also cause behavior (1)? Chrome used to make that equivalent to reload but it was a huge perf issue. Now that reload only revalidates the main resource I think it makes sense to restore that behavior.

FWIW, one of the issues with location.href = location.href is that the behavior is different depending on if you have a hash. Eg, if you are on https://www.facebook.com/#foo, location.href=location.href does nothing (because it is treated as navigating to the #foo anchor). This is why reload() has snuck into the FB codebase -- because before html5 history there were a number of situations where we needed to do a fresh page load *and* change the hash.

I agree that making reload() have the same semantics as the refresh button would be great for the simplicity and understandability of the platform.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

[Ojan Vafai]

Yes, I'd put navigating to the same URL via the URL bar in the same category.

Thanks for clarifying about hash urls. I think the right way to think about that is that changing the hash (even to the same value) does not reload at all. But any changes to url that cause a reload should do the same reload behavior as the other ways of reloading.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABgOVaKvJdmzZ4ztOdFUF%2BZePr7L9R5F6WxhaEi7xBtOW94jYw%40mail.gmail.com.

[Takashi Toyoshima]

Thank you, Ojan.

I should explain that we are trying to have exactly two kinds of reloads in the first mail, but anyway let me update the list.

1. Uses the cache and forcibly revalidates only the main resource:
   

1. reload button
2. f5/cmd+r
3. location.reload
4. location.href = location.href

1. same page navigation (Omnibox-Enter in the same page)
2. Pull to refresh

1. Doesn't use the cache

1. location.reload(bool)
2. shift+refresh
3. TBD: mobile new gesture (consecutive reloads?)

Ojan:

I agreed this category. It's also reasonable to add bool for location.reload() to provide a way not to use the cache for JavaScript.

Chris:

Good point. Actually, I just started measuring reload-to-reload time duration in user actions for such purpose. We discussed with UX team, and current plan is to trigger shift+reload if a user initiates another reload in a few seconds from the last reload without taking another navigation.

Ben:

Yes, hitting an enter in the same URL should result in a reload that revalidates only the main resource in Chrome.

Also, you are right. we should keep the same behavior for hash URLs. This is defined in the navigation spec as a "Navigating to a fragment".

Note: Chrome has a bug that a meta refresh to the same page with hash results in a reload, but expectation should be scrolling to the fragment.

Also we have some points that have minor differences on reloads. I'd remove such minor differences to simplify reloads.

 - scroll position restoration => should always follow History.scrollRestoration flag

 - user state restoration, e.g., scaling factor (HTML spec issue at GitHub) => should be restored always

Same page navigation does not restore user states today, but we will do after the new reload rolling out.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABgOVaKvJdmzZ4ztOdFUF%2BZePr7L9R5F6WxhaEi7xBtOW94jYw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwmtA-9FEngFydC8nPPCWo3dx6vKvNBfKU0yOV1ro5uQ%40mail.gmail.com.

[Ojan Vafai]

On Thu, Oct 13, 2016 at 7:02 PM Takashi Toyoshima <toyo...@chromium.org> wrote:

Thank you, Ojan.

I should explain that we are trying to have exactly two kinds of reloads in the first mail, but anyway let me update the list.

1. Uses the cache and forcibly revalidates only the main resource:
   

1. reload button
2. f5/cmd+r
3. location.reload
4. location.href = location.href

1. same page navigation (Omnibox-Enter in the same page)
2. Pull to refresh

1. Doesn't use the cache

1. location.reload(bool)
2. shift+refresh
3. TBD: mobile new gesture (consecutive reloads?)

Ojan:

I agreed this category. It's also reasonable to add bool for location.reload() to provide a way not to use the cache for JavaScript.

To be clear, I have no opinion on whether we should add the bool to location.reload. Either way seems fine to me. :) I just meant that if we do, it should be the same as shift+refresh.

 

Chris:

Good point. Actually, I just started measuring reload-to-reload time duration in user actions for such purpose. We discussed with UX team, and current plan is to trigger shift+reload if a user initiates another reload in a few seconds from the last reload without taking another navigation.

Do we have evidence this is necessary? Or are we planning to consider it only if we find cases?

I'm a bit worried about this messing with people testing the performance of sites that they build. Their site will randomly take forever to load as they're testing it.

 

Ben:

Yes, hitting an enter in the same URL should result in a reload that revalidates only the main resource in Chrome.

Also, you are right. we should keep the same behavior for hash URLs. This is defined in the navigation spec as a "Navigating to a fragment".

Note: Chrome has a bug that a meta refresh to the same page with hash results in a reload, but expectation should be scrolling to the fragment.

Also we have some points that have minor differences on reloads. I'd remove such minor differences to simplify reloads.

 - scroll position restoration => should always follow History.scrollRestoration flag

 - user state restoration, e.g., scaling factor (HTML spec issue at GitHub) => should be restored always

Same page navigation does not restore user states today, but we will do after the new reload rolling out.

In general, I'm super happy to see these things unified. Thanks for working on this!

 

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABgOVaKvJdmzZ4ztOdFUF%2BZePr7L9R5F6WxhaEi7xBtOW94jYw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwmtA-9FEngFydC8nPPCWo3dx6vKvNBfKU0yOV1ro5uQ%40mail.gmail.com.

--

Takashi Toyoshima
Software Engineer, Google

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1%3DA%2BopnAYfw0jFybX8kXjKSak-aFrZmyeVxVE9aDjJw1A%40mail.gmail.com.

[Kenji Baheux]

+1 on converging on 2 behaviors (it was indeed the plan from the start :D)

On Fri, Oct 14, 2016 at 11:14 AM Ojan Vafai <oj...@chromium.org> wrote:

On Thu, Oct 13, 2016 at 7:02 PM Takashi Toyoshima <toyo...@chromium.org> wrote:

Thank you, Ojan.

I should explain that we are trying to have exactly two kinds of reloads in the first mail, but anyway let me update the list.

1. Uses the cache and forcibly revalidates only the main resource:
   

1. reload button
2. f5/cmd+r
3. location.reload
4. location.href = location.href

1. same page navigation (Omnibox-Enter in the same page)
2. Pull to refresh

1. Doesn't use the cache

1. location.reload(bool)
2. shift+refresh
3. TBD: mobile new gesture (consecutive reloads?)

Ojan:

I agreed this category. It's also reasonable to add bool for location.reload() to provide a way not to use the cache for JavaScript.

To be clear, I have no opinion on whether we should add the bool to location.reload. Either way seems fine to me. :) I just meant that if we do, it should be the same as shift+refresh.

 

Chris:

Good point. Actually, I just started measuring reload-to-reload time duration in user actions for such purpose. We discussed with UX team, and current plan is to trigger shift+reload if a user initiates another reload in a few seconds from the last reload without taking another navigation.

Do we have evidence this is necessary? Or are we planning to consider it only if we find cases?

Context: this is being explored but only for mobile because we are taking away some of the "can fix a broken page" potential from the traditional Reload. This could theoretically be problematic given that there is no hard reload gesture on mobile.

UX suggested that we explore triggering a hard reload on fast-subsequent pull-to-refresh gestures instead of additional UX surface or hard to discover alternatives.

Toyoshima-san landed UMA to help us understand if this could work.

We'll iterate with the UX team.

 

I'm a bit worried about this messing with people testing the performance of sites that they build. Their site will randomly take forever to load as they're testing it.

Definitely. We'll keep this in mind.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTto1T1A%3DMnYvsuhXxC7eSrVHNRCkTS2QA%2Byp-MHQFPp5g%40mail.gmail.com.

[Takashi Toyoshima]

On Fri, Oct 14, 2016 at 11:31 AM, Kenji Baheux <kenji...@chromium.org> wrote:

+1 on converging on 2 behaviors (it was indeed the plan from the start :D)

On Fri, Oct 14, 2016 at 11:14 AM Ojan Vafai <oj...@chromium.org> wrote:

On Thu, Oct 13, 2016 at 7:02 PM Takashi Toyoshima <toyo...@chromium.org> wrote:

Thank you, Ojan.

I should explain that we are trying to have exactly two kinds of reloads in the first mail, but anyway let me update the list.

1. Uses the cache and forcibly revalidates only the main resource:
   

1. reload button
2. f5/cmd+r
3. location.reload
4. location.href = location.href

1. same page navigation (Omnibox-Enter in the same page)
2. Pull to refresh

1. Doesn't use the cache

1. location.reload(bool)
2. shift+refresh
3. TBD: mobile new gesture (consecutive reloads?)

Ojan:

I agreed this category. It's also reasonable to add bool for location.reload() to provide a way not to use the cache for JavaScript.

To be clear, I have no opinion on whether we should add the bool to location.reload. Either way seems fine to me. :) I just meant that if we do, it should be the same as shift+refresh.

I'm asking at whatwg if there was a historical reason why standardized location.reload() didn't take a boolean, but Firefox did. If there was no strong reason, I prefer to add boolean because it won't affect code complexity in Blink, and make this change safer.

Ben, if you know location.reload(true) is completely useless, please let me know. In such case, probably I shouldn't add it.

Also I noticed that "location.href = location.href" should be same with location.reload() only when it is called in the top frame. On the other hand, location.reload() and history.go(0) triggers a reload against the top frame even though the method is called in one of sub frames.

Sorry, this is minor matters, but just in case.

 

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABgOVaKvJdmzZ4ztOdFUF%2BZePr7L9R5F6WxhaEi7xBtOW94jYw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwmtA-9FEngFydC8nPPCWo3dx6vKvNBfKU0yOV1ro5uQ%40mail.gmail.com.

--

Takashi Toyoshima
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1%3DA%2BopnAYfw0jFybX8kXjKSak-aFrZmyeVxVE9aDjJw1A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTto1T1A%3DMnYvsuhXxC7eSrVHNRCkTS2QA%2Byp-MHQFPp5g%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CADWWn7UTJxezHRxGChwQXEfLT%2BH-0ECxhgy42TsTa87J2P5_OQ%40mail.gmail.com.

[Ben Maurer]

Having the force reload override is useful. It's actually one of the few ways a site like FB could help somebody fix cache corruption without asking them to clear their cache manually. I'm not sure we'd actually use it (right now we do this by setting a cookie with a cache breaker). But if it's a minimal amount of code and also helps us make this change safely I'm all for it.

One other thought -- if we're really worried about web compatibility we could make passing false not do any revalidation while keeping today's behavior in the case of no arguments.

Sent from my iPhone

[Ojan Vafai]

I'm not particularly worried about web compat here. That said, I agree that adding the bool gives authors the ability to fix any issues we might cause with this change. And, it seems generally useful to give web sites a way to deal with cache corruption. I don't see any downsides to shipping it, so we may as well?

I don't think we should do something different for the no-argument and false cases though. I'd really like for us to end up with exactly two kinds of reload on the platform.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABgOVaKvJdmzZ4ztOdFUF%2BZePr7L9R5F6WxhaEi7xBtOW94jYw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwmtA-9FEngFydC8nPPCWo3dx6vKvNBfKU0yOV1ro5uQ%40mail.gmail.com.

--

Takashi Toyoshima
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1%3DA%2BopnAYfw0jFybX8kXjKSak-aFrZmyeVxVE9aDjJw1A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTto1T1A%3DMnYvsuhXxC7eSrVHNRCkTS2QA%2Byp-MHQFPp5g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CADWWn7UTJxezHRxGChwQXEfLT%2BH-0ECxhgy42TsTa87J2P5_OQ%40mail.gmail.com.

--

Takashi Toyoshima
Software Engineer, Google

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/719E1DEB-2445-45ED-A7AE-D660A754D2A3%40gmail.com.

[Takashi Toyoshima]

Updates (crbug.com/670237)

Now, I finished to implement new location.reload() that revalidates only the main resource.

The feature is managed by field trial flags, but you can manually enable it through one of following flags (only on recent Canary now).

 - chrome://flags/#enable-experimental-web-platform-features

 - chrome://flags/#enable-faster-location-reload

I will try enabling it on m57 by default through the server side configuration. The field study will start early Jan 2017.

FYI, my current thoughts about bool flag of location.reload():

I read some threads that annevk at mozilla tell me, and at this point, I prefer not changing it if it's acceptable. That's because some features may want to consider to hook it up if it's there, i.e. ServiceWorker, and it could raise several discussions like what kind of information should be reset on the force reload, and actually I've seen some opinions at crbugs. Our answer for it is "please use DevTools". So, IMO, not having bool flag provides a consistent design for developers.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABgOVaKvJdmzZ4ztOdFUF%2BZePr7L9R5F6WxhaEi7xBtOW94jYw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTtwmtA-9FEngFydC8nPPCWo3dx6vKvNBfKU0yOV1ro5uQ%40mail.gmail.com.

--

Takashi Toyoshima
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1%3DA%2BopnAYfw0jFybX8kXjKSak-aFrZmyeVxVE9aDjJw1A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTto1T1A%3DMnYvsuhXxC7eSrVHNRCkTS2QA%2Byp-MHQFPp5g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CADWWn7UTJxezHRxGChwQXEfLT%2BH-0ECxhgy42TsTa87J2P5_OQ%40mail.gmail.com.

--

Takashi Toyoshima
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/719E1DEB-2445-45ED-A7AE-D660A754D2A3%40gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTvJEOOxttVaQ_E8p-cKKGSaDOdWVBJ%3D_OZmBN_9i1XPdQ%40mail.gmail.com.

[Ojan Vafai]

Sgtm. Thanks for continuing to make sense of reload. :)

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABgOVaKvJdmzZ4ztOdFUF%2BZePr7L9R5F6WxhaEi7xBtOW94jYw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.

[Takashi Toyoshima]

Hi loading-dev,

As I planned, the location.reload() behavior is going to be changed on m57 stable channel after some field trial steps.

I just flipped the final piece of server side configurations to roll out this behavior change for all users on all channels.

You will receive the new configuration in a few days.

Thanks,

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAFWCB1nPt7W-qKSBHJHPrFYq7NGzvbuknVBVLU9tFUVe5QjYiw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CANMdWTu2Lnudrjt1hjrjUwPxD%2BkyhCL-y02_icn4kQW8aXEeMQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CABgOVaKvJdmzZ4ztOdFUF%2BZePr7L9R5F6WxhaEi7xBtOW94jYw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.

To post to this group, send email to loadi...@chromium.org.

[Chris Bentzel]

Very exciting!

[Charles Harrison]

Is there a performance win for this change? What portion of page loads come from location.reload?

--

You received this message because you are subscribed to the Google Groups "Chromium Loading Performance" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.
To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CAAuiYA97G0DRjHvY%2B3okpW7PDdb7esFHKhuZ0jArBmY70H%3DgiQ%40mail.gmail.com.

[Takashi Toyoshima]

This isn't for performance, but just to be consistent with UI behavior. Also, I can remove legacy reload behavior completely from Blink code base after this change.

Actually, I could not find any statistically significant difference between two study groups in the past.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CADjAqN6Jc9UfMbx67rr6-%3DOes26Gt%2BKhxy4uEo_pYQiev397rg%40mail.gmail.com.

[Charles Harrison]

Yeah I understand the change was for consistency, just wondering if it also boosts performance :) Thanks for the update.

[Ojan Vafai]

\o/ Thanks for following up! One fewer quirk for web (and Chrome) developers to make sense of. :)

[Ben Maurer]

Thanks for finally fixing this! We were still seeing single-digit percents of 304 requests so this change will have a slight positive perf impact. In a week or so I'll see how our logs have changed as the server side config rolls out.

[Ben Maurer]

Hey guys --

I'm happy to report that our stats are showing that this change has eliminated another 3% of requests to our CDN. This is a graph of the percent of JS/CSS requests from Chrome 57 to our CDN that result in 304s. Any ideas where that last 1% might be coming from?

[Kenji Baheux]

Thanks for sharing!

Re the last 1%: hints would help...

Are you seeing any discrepancies depending on how you slice the data?

• mobile vs. not
• countries
• connection type
• stable vs. beta/dev/canary channels
  
• sub-resource: type, FB widget related vs. main website resources

[Takashi Toyoshima]

Updates,

Sorry for short notice, but I'm now temporarily disable the location.reload() change on m58 stable for some investigations.

I will make it back once my investigation is finished, or on m59.

[sac...@gmail.com]

How long does a standard reload take and should I be concerned?

[Takashi Toyoshima]

On Thu, Aug 17, 2017 at 1:51 AM, <sac...@gmail.com> wrote:

How long does a standard reload take and should I be concerned?

Hi, could you elaborate your questions?

What does "a standard reload" mean here, and taking time for what is what you asked?

 

--
You received this message because you are subscribed to the Google Groups "loading-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev+unsubscribe@chromium.org.
To post to this group, send email to loadi...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/8d9031b5-2b69-4718-9753-5ad974190f43%40chromium.org.