Intent to Ship: Background tab loading throttling with ResourceLoadScheduler

[Kinuko Yasuda]

Contact emails

toyo...@chromium.org, ksak...@chromium.org, kin...@chromium.org

Summary:

Throttle resource loading in background by capping the # of maximum concurrent requests at once. We’ve been running various experiments for a while, and are planning to ship this feature. This feature is not spec-breaking and are not really Web visible by definition, while developers or users can still possibly notice slow loads in background.

Link to “Intent to Implement” blink-dev discussion:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/iS0Szd-GD7E/n27gJoBpCAAJ

Motivation:

Aggressive loading activities on background tabs are known to a source of slowness on foreground tabs. In order to maximize user experience we want to throttle loading in background so that they can still make progress (until the tab gets frozen) but do not degrade loading performance in foreground.

Our data (UMA) showed statistically significant improvements (3~4%) on loading metrics both on FCP and FMP on foreground tabs. With targeted metrics the data showed bigger improvements when multiple tabs are open (e.g. ~6% improvements with 3+ loading tabs, and ~12% improvements with 5+ loading tabs).

Is this feature supported on all six Blink platforms?

Yes.

Risks:

Interoperability and Compatibility:
This is basically an internal detail of throttling and should not cause any interoperability risks.  Initial experiments introduced some sites breakages, but we addressed all of them.

Ergonomics

N/A

Activation

None required.

Avoidability (as an intervention)
In common cases issuing aggressive concurrent loading requests in background should be done in the way that does not degrade foreground user experience. For specific cases where this behavior is undesirable we are considering providing a feature flag or policy to opt-out.

Debuggability:

We are adding console warning when requests are throttled by this feature in M69.

Requesting approval to ship?

Yes.  (Additional context: currently this feature is enabled for 50% on Canary/Dev/Beta)

[Yoav Weiss]

Thanks for working on this. I'm highly supportive of efforts on that front! 

On Fri, Jun 29, 2018 at 11:31 AM Kinuko Yasuda <kin...@chromium.org> wrote:

Contact emails

toyo...@chromium.org, ksak...@chromium.org, kin...@chromium.org

Summary:

Throttle resource loading in background by capping the # of maximum concurrent requests at once. We’ve been running various experiments for a while, and are planning to ship this feature. This feature is not spec-breaking and are not really Web visible by definition, while developers or users can still possibly notice slow loads in background.

What is the current number of maximum concurrent requests?

Are there plans to experiment further with that number, or are you confident that the current one is the "right" one for the long term?

As a future effort, I'd also love to see some flow-control throttling at the network layer for streams originating from background or low-priority fetches. (as a small number of requests can also do a lot of bandwidth damage)

 

Link to “Intent to Implement” blink-dev discussion:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/iS0Szd-GD7E/n27gJoBpCAAJ

Motivation:

Aggressive loading activities on background tabs are known to a source of slowness on foreground tabs. In order to maximize user experience we want to throttle loading in background so that they can still make progress (until the tab gets frozen) but do not degrade loading performance in foreground.

Our data (UMA) showed statistically significant improvements (3~4%) on loading metrics both on FCP and FMP on foreground tabs. With targeted metrics the data showed bigger improvements when multiple tabs are open (e.g. ~6% improvements with 3+ loading tabs, and ~12% improvements with 5+ loading tabs).

That's awesome! :)

 

Is this feature supported on all six Blink platforms?

Yes.

Risks:

Interoperability and Compatibility:
This is basically an internal detail of throttling and should not cause any interoperability risks.  Initial experiments introduced some sites breakages, but we addressed all of them.

Could you detail some of the breakage? I'm surprised there was any...

 

Ergonomics

N/A

Activation

None required.

Avoidability (as an intervention)
In common cases issuing aggressive concurrent loading requests in background should be done in the way that does not degrade foreground user experience. For specific cases where this behavior is undesirable we are considering providing a feature flag or policy to opt-out.

Can you expand on that?

 

Debuggability:

We are adding console warning when requests are throttled by this feature in M69.

Might be good to integrate that with the Reporting API (in the future), as this may be something that will not happen in the developer's testing environment, but will happen in the wild.

From a RUM perspective, analytics providers will have to pay attention to the page's visibility state, as they'd need to split background loads from foreground loads. But I think the currently exposed APIs are enough for that.

 

Requesting approval to ship?

Yes.  (Additional context: currently this feature is enabled for 50% on Canary/Dev/Beta)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNYm9oGvcwnRWtLVHOjaWwxmDuTCi-1piAJ5xnPQUnx%3D7g%40mail.gmail.com.

[Kinuko Yasuda]

Thanks for the comments/questions!

On Fri, Jun 29, 2018 at 7:30 PM Yoav Weiss <yo...@yoav.ws> wrote:

Thanks for working on this. I'm highly supportive of efforts on that front! 

On Fri, Jun 29, 2018 at 11:31 AM Kinuko Yasuda <kin...@chromium.org> wrote:

Contact emails

toyo...@chromium.org, ksak...@chromium.org, kin...@chromium.org

Summary:

Throttle resource loading in background by capping the # of maximum concurrent requests at once. We’ve been running various experiments for a while, and are planning to ship this feature. This feature is not spec-breaking and are not really Web visible by definition, while developers or users can still possibly notice slow loads in background.

What is the current number of maximum concurrent requests?

Are there plans to experiment further with that number, or are you confident that the current one is the "right" one for the long term?

​

​​

Current max is three for​ main frames and two for subframes.​  For now we're satisfied with the current configuration, but different parameters can be tested further and we're open to do additional adjustments whenever needed.

 ​​

As a future effort, I'd also love to see some flow-control throttling at the network layer for streams originating from background or low-priority fetches. (as a small number of requests can also do a lot of bandwidth damage)

​Yeah current throttling logic is pretty ​simple (which has its own benefit) and I agree that there're things we can improve like flow-control or some back pressuring.

Link to “Intent to Implement” blink-dev discussion:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/iS0Szd-GD7E/n27gJoBpCAAJ

Motivation:

Aggressive loading activities on background tabs are known to a source of slowness on foreground tabs. In order to maximize user experience we want to throttle loading in background so that they can still make progress (until the tab gets frozen) but do not degrade loading performance in foreground.

Our data (UMA) showed statistically significant improvements (3~4%) on loading metrics both on FCP and FMP on foreground tabs. With targeted metrics the data showed bigger improvements when multiple tabs are open (e.g. ~6% improvements with 3+ loading tabs, and ~12% improvements with 5+ loading tabs).

That's awesome! :)

 

Is this feature supported on all six Blink platforms?

Yes.

Risks:

Interoperability and Compatibility:
This is basically an internal detail of throttling and should not cause any interoperability risks.  Initial experiments introduced some sites breakages, but we addressed all of them.

Could you detail some of the breakage? I'm surprised there was any...

The existing logic doesn't really detect hanging-gets, i.e. long running GETs that can prevent other requests from going when # of inflight requests is capped.  Most of these requests use fetch, WebSocket or WebRTC, but in some cases they fall back to do this over XHR (e.g. some proxies don't support WebSocket) so we excluded XHR from throttleable requests.  (We're aware that a better longer-term solution might be to detect hanging gets, but we are not yet fully sure if it's worth investing)

Ergonomics

N/A

Activation

None required.

Avoidability (as an intervention)
In common cases issuing aggressive concurrent loading requests in background should be done in the way that does not degrade foreground user experience. For specific cases where this behavior is undesirable we are considering providing a feature flag or policy to opt-out.

Can you expand on that?

In general we believe that aggressive concurrent requests should be throttled (or paused at some point) in background, while we also hear that, say, there can be Enterprise sites that have specific target users and purposes therefore those sites care more about the tasks initiated are completed (regardless of whether background fetches are used or not) rather than providing good user experience.  We do want to provide a way for the sites / such usages to opt-out this behavior, maybe *any* background throttling. (Discussion is still in-progress and we're not fully settled on this one yet)

Debuggability:

We are adding console warning when requests are throttled by this feature in M69.

Might be good to integrate that with the Reporting API (in the future), as this may be something that will not happen in the developer's testing environment, but will happen in the wild.

​Yep, integration with Reporting API can be a plausible future work and can file an issue if it looks it's desirable.​

[Daniel Bratell]

Seems like it is important to distinguish between persistent connections (where waiting for them to close is futile) and fetches (i.e. an updated ad) to avoid starving pages. Especially when the limit is as low as 3. 

You write that you have excluded XHR from the counter, but why not also exclude webrtc streams, plugin streams, video streams and websocket connections that can also be persistent connections? Or exclude any connection that has been open a long time if that information is available.

One concern with such good results is that something was broken. If pages were hung in the background, would there be any way to know from metrics?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNabbX5six78v-hmxPUzyBrUziK2Z1Ht-E3M0KO70aHc9w%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Kinuko Yasuda]

Thanks for the comments!

On Thu, Jul 5, 2018 at 10:00 PM Daniel Bratell <bra...@opera.com> wrote:

Seems like it is important to distinguish between persistent connections (where waiting for them to close is futile) and fetches (i.e. an updated ad) to avoid starving pages. Especially when the limit is as low as 3. 

You write that you have excluded XHR from the counter, but why not also exclude webrtc streams, plugin streams, video streams and websocket connections that can also be persistent connections? Or exclude any connection that has been open a long time if that information is available.

WebRTC and WebSocket are out of scope of this throttling therefore they are not throttled by this, and additionally to be conservative currently Chrome does NOT throttle the frames that have active connections of these types even with this feature.

 

One concern with such good results is that something was broken. If pages were hung in the background, would there be any way to know from metrics?

Yeah it's a fair concern, we've been checking some metrics that potentially can indicate bad signals like page load abort rate, but we hadn't observed statically significant changes there.​  Also even with this feature once a user goes back to the tab things should just start working again, so the expectation was that things should not be really broken.  That's said wide roll-out could of course end up with more undesirable breakages, and if that happens we're willing to share that here and will roll it back soon until we make a fix.  (We make the configuration changeable on the server side, so that the fix should not need to wait for another milestone.)

[Philip Jägenstedt]

Yoav, Daniel, any further concerns? (I haven't looked closely yet.)

​

 

Thanks for the comments/questions!

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNYm9oGvcwnRWtLVHOjaWwxmDuTCi-1piAJ5xnPQUnx%3D7g%40mail.gmail.com.

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNabbX5six78v-hmxPUzyBrUziK2Z1Ht-E3M0KO70aHc9w%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNZpYwLv7NzKyfQdNNvxKUzQXZ7BV9oRLC7whL-nP4ZsMw%40mail.gmail.com.

[Daniel Bratell]

I'm still worried about it breaking pages, but I think kinuko's data is a good indication that it will go well. Should other resource in the future be exposed to the same throttling, that might require further changes, but for now it seems ready to go.

LGTM1

/Daniel

​

 

Thanks for the comments/questions!

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNYm9oGvcwnRWtLVHOjaWwxmDuTCi-1piAJ5xnPQUnx%3D7g%40mail.gmail.com.

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNabbX5six78v-hmxPUzyBrUziK2Z1Ht-E3M0KO70aHc9w%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNZpYwLv7NzKyfQdNNvxKUzQXZ7BV9oRLC7whL-nP4ZsMw%40mail.gmail.com.

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_uWHtOdryu%2B7GV7m6XV1i3h30SxAeLKjLAQbOcPw-8eL%3DVYw%40mail.gmail.com.

[Shubhie Panicker]

Thanks for the Intent and the details Kinuko!

We do want to provide a way for the sites / such usages to opt-out this behavior, maybe *any* background throttling. (Discussion is still in-progress and we're not fully settled on this one yet)

This seems like the main issue to sort out as part of the I2S:

• Is the opt-out necessary (assuming developer opt-out)? 
• Is it a temporary or permanent opt-out? 
• Does it need to be developer controlled (eg origin trial) or would we maintain our own internal database of opted out origins?
  

Re: using more general background opt-out, it's unclear how it fits there:

• For background throttling (in general) there isn't any long term developer opt-out planned, only user opt-out eg. for worker throttling.
• For background freezing / discarding - the plan is to have a temporary developer opt-outs during the rollout and until relevant APIs become available.

Perhaps the following Qs might help understand the need for opt-out better:

- Which enterprise use-cases are adversely affected?

- What alternatives (eg. addition of grace time etc) have been considered to help these cases rather than full opt-out?

 

​

 

Thanks for the comments/questions!

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNYm9oGvcwnRWtLVHOjaWwxmDuTCi-1piAJ5xnPQUnx%3D7g%40mail.gmail.com.

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNabbX5six78v-hmxPUzyBrUziK2Z1Ht-E3M0KO70aHc9w%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNZpYwLv7NzKyfQdNNvxKUzQXZ7BV9oRLC7whL-nP4ZsMw%40mail.gmail.com.

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ_uWHtOdryu%2B7GV7m6XV1i3h30SxAeLKjLAQbOcPw-8eL%3DVYw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zlzq50wvrbppqq%40cicero2.linkoping.osa.

[Chris Harrelson]

On Fri, Jul 6, 2018 at 2:33 AM Kinuko Yasuda <kin...@chromium.org> wrote:

Thanks for the comments!

On Thu, Jul 5, 2018 at 10:00 PM Daniel Bratell <bra...@opera.com> wrote:

Seems like it is important to distinguish between persistent connections (where waiting for them to close is futile) and fetches (i.e. an updated ad) to avoid starving pages. Especially when the limit is as low as 3. 

You write that you have excluded XHR from the counter, but why not also exclude webrtc streams, plugin streams, video streams and websocket connections that can also be persistent connections? Or exclude any connection that has been open a long time if that information is available.

WebRTC and WebSocket are out of scope of this throttling therefore they are not throttled by this, and additionally to be conservative currently Chrome does NOT throttle the frames that have active connections of these types even with this feature.

You are not counting XHR, WebRTC or WebSocket at all, is that right? Could you enumerate exactly what is being counted and therefore throttled?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNZpYwLv7NzKyfQdNNvxKUzQXZ7BV9oRLC7whL-nP4ZsMw%40mail.gmail.com.

[Yoav Weiss]

LGTM2

(re-sending a previously sent LGTM, this time as "reply all" :/)

Agree that some opt-out for webapps that have common background usage use-cases makes sense, and this could potentially share the opt-out mechanism with other background throttling efforts.

 

Debuggability:

We are adding console warning when requests are throttled by this feature in M69.

Might be good to integrate that with the Reporting API (in the future), as this may be something that will not happen in the developer's testing environment, but will happen in the wild.

​Yep, integration with Reporting API can be a plausible future work and can file an issue if it looks it's desirable.​

I think it is.

[Yoav Weiss]

On Wed, Jul 11, 2018 at 2:33 PM Philip Jägenstedt <foo...@chromium.org> wrote:

Yoav, Daniel, any further concerns? (I haven't looked closely yet.)

No other concerns on my end. +1 to Chris' request to enumerate which types of resource loads this will be applied to.

 

​

 

Thanks for the comments/questions!

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNYm9oGvcwnRWtLVHOjaWwxmDuTCi-1piAJ5xnPQUnx%3D7g%40mail.gmail.com.

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNabbX5six78v-hmxPUzyBrUziK2Z1Ht-E3M0KO70aHc9w%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

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

[Kinuko Yasuda]

On Thu, Jul 12, 2018 at 3:07 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jul 6, 2018 at 2:33 AM Kinuko Yasuda <kin...@chromium.org> wrote:

Thanks for the comments!

On Thu, Jul 5, 2018 at 10:00 PM Daniel Bratell <bra...@opera.com> wrote:

Seems like it is important to distinguish between persistent connections (where waiting for them to close is futile) and fetches (i.e. an updated ad) to avoid starving pages. Especially when the limit is as low as 3. 

You write that you have excluded XHR from the counter, but why not also exclude webrtc streams, plugin streams, video streams and websocket connections that can also be persistent connections? Or exclude any connection that has been open a long time if that information is available.

WebRTC and WebSocket are out of scope of this throttling therefore they are not throttled by this, and additionally to be conservative currently Chrome does NOT throttle the frames that have active connections of these types even with this feature.

You are not counting XHR, WebRTC or WebSocket at all, is that right? Could you enumerate exactly what is being counted and therefore throttled?

Right reg: the first question.  Reg: the second question: most fetches made by HTML elements / stylesheets are throttleable, those include: scripts, images, fonts, stylesheets, frame resources, workers, object/plugins, preloads of these, prefetches and CSP reports.

[Yoav Weiss]

On Tue, Jul 17, 2018 at 11:01 AM Kinuko Yasuda <kin...@chromium.org> wrote:

On Thu, Jul 12, 2018 at 3:07 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jul 6, 2018 at 2:33 AM Kinuko Yasuda <kin...@chromium.org> wrote:

Thanks for the comments!

On Thu, Jul 5, 2018 at 10:00 PM Daniel Bratell <bra...@opera.com> wrote:

Seems like it is important to distinguish between persistent connections (where waiting for them to close is futile) and fetches (i.e. an updated ad) to avoid starving pages. Especially when the limit is as low as 3. 

You write that you have excluded XHR from the counter, but why not also exclude webrtc streams, plugin streams, video streams and websocket connections that can also be persistent connections? Or exclude any connection that has been open a long time if that information is available.

WebRTC and WebSocket are out of scope of this throttling therefore they are not throttled by this, and additionally to be conservative currently Chrome does NOT throttle the frames that have active connections of these types even with this feature.

You are not counting XHR, WebRTC or WebSocket at all, is that right? Could you enumerate exactly what is being counted and therefore throttled?

Right reg: the first question.  Reg: the second question: most fetches made by HTML elements / stylesheets are throttleable, those include: scripts, images, fonts, stylesheets, frame resources, workers, object/plugins, preloads of these, prefetches and CSP reports.

Are media resources (video, audio and track) throttled?

[Kinuko Yasuda]

On Tue, Jul 17, 2018 at 8:53 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Jul 17, 2018 at 11:01 AM Kinuko Yasuda <kin...@chromium.org> wrote:

On Thu, Jul 12, 2018 at 3:07 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jul 6, 2018 at 2:33 AM Kinuko Yasuda <kin...@chromium.org> wrote:

Thanks for the comments!

On Thu, Jul 5, 2018 at 10:00 PM Daniel Bratell <bra...@opera.com> wrote:

Seems like it is important to distinguish between persistent connections (where waiting for them to close is futile) and fetches (i.e. an updated ad) to avoid starving pages. Especially when the limit is as low as 3. 

You write that you have excluded XHR from the counter, but why not also exclude webrtc streams, plugin streams, video streams and websocket connections that can also be persistent connections? Or exclude any connection that has been open a long time if that information is available.

WebRTC and WebSocket are out of scope of this throttling therefore they are not throttled by this, and additionally to be conservative currently Chrome does NOT throttle the frames that have active connections of these types even with this feature.

You are not counting XHR, WebRTC or WebSocket at all, is that right? Could you enumerate exactly what is being counted and therefore throttled?

Right reg: the first question.  Reg: the second question: most fetches made by HTML elements / stylesheets are throttleable, those include: scripts, images, fonts, stylesheets, frame resources, workers, object/plugins, preloads of these, prefetches and CSP reports.

Are media resources (video, audio and track) throttled?

​We used to, but per the recent observations (i.e. throttling long-running gets can be riskier) we recently excluded them from the throttleable category.​

[Yoav Weiss]

On Tue, Jul 17, 2018 at 2:05 PM Kinuko Yasuda <kin...@chromium.org> wrote:

On Tue, Jul 17, 2018 at 8:53 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Jul 17, 2018 at 11:01 AM Kinuko Yasuda <kin...@chromium.org> wrote:

On Thu, Jul 12, 2018 at 3:07 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jul 6, 2018 at 2:33 AM Kinuko Yasuda <kin...@chromium.org> wrote:

Thanks for the comments!

On Thu, Jul 5, 2018 at 10:00 PM Daniel Bratell <bra...@opera.com> wrote:

Seems like it is important to distinguish between persistent connections (where waiting for them to close is futile) and fetches (i.e. an updated ad) to avoid starving pages. Especially when the limit is as low as 3. 

You write that you have excluded XHR from the counter, but why not also exclude webrtc streams, plugin streams, video streams and websocket connections that can also be persistent connections? Or exclude any connection that has been open a long time if that information is available.

WebRTC and WebSocket are out of scope of this throttling therefore they are not throttled by this, and additionally to be conservative currently Chrome does NOT throttle the frames that have active connections of these types even with this feature.

You are not counting XHR, WebRTC or WebSocket at all, is that right? Could you enumerate exactly what is being counted and therefore throttled?

Right reg: the first question.  Reg: the second question: most fetches made by HTML elements / stylesheets are throttleable, those include: scripts, images, fonts, stylesheets, frame resources, workers, object/plugins, preloads of these, prefetches and CSP reports.

Are media resources (video, audio and track) throttled?

​We used to, but per the recent observations (i.e. throttling long-running gets can be riskier) we recently excluded them from the throttleable category.​

OK, thanks for clarifying.

[Chris Harrelson]

LGTM3

On Tue, Jul 17, 2018 at 5:17 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Jul 17, 2018 at 2:05 PM Kinuko Yasuda <kin...@chromium.org> wrote:

On Tue, Jul 17, 2018 at 8:53 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Jul 17, 2018 at 11:01 AM Kinuko Yasuda <kin...@chromium.org> wrote:

On Thu, Jul 12, 2018 at 3:07 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jul 6, 2018 at 2:33 AM Kinuko Yasuda <kin...@chromium.org> wrote:

Thanks for the comments!

On Thu, Jul 5, 2018 at 10:00 PM Daniel Bratell <bra...@opera.com> wrote:

Seems like it is important to distinguish between persistent connections (where waiting for them to close is futile) and fetches (i.e. an updated ad) to avoid starving pages. Especially when the limit is as low as 3. 

You write that you have excluded XHR from the counter, but why not also exclude webrtc streams, plugin streams, video streams and websocket connections that can also be persistent connections? Or exclude any connection that has been open a long time if that information is available.

WebRTC and WebSocket are out of scope of this throttling therefore they are not throttled by this, and additionally to be conservative currently Chrome does NOT throttle the frames that have active connections of these types even with this feature.

You are not counting XHR, WebRTC or WebSocket at all, is that right? Could you enumerate exactly what is being counted and therefore throttled?

Right reg: the first question.  Reg: the second question: most fetches made by HTML elements / stylesheets are throttleable, those include: scripts, images, fonts, stylesheets, frame resources, workers, object/plugins, preloads of these, prefetches and CSP reports.

It sounds like you are throttling declarative resources (except for media), and omitting imperative ones. That makes some sense to me, and less likely to cause compat problems.

 

Please add detail about what is being throttled to the chromestatus entry, as an additional aid to developers.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEit7kMnOqKcy%2BsPeLHJqBPHY%2BSK-GOa7b5%2B7ujrWCM-uQ%40mail.gmail.com.

[Kinuko Yasuda]

​​

On Wed, Jul 18, 2018 at 3:15 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

... 

​​

It sounds like you are throttling declarative resources (except for media), and omitting imperative ones. That makes some sense to me, and less likely to cause compat problems.

 

Please add detail about what is being throttled to the chromestatus entry, as an additional aid to developers.

​Thanks Chris, just done.​

And Shubhie: Haven't replied to this yet, sorry!

On Thu, Jul 12, 2018 at 3:00 AM Shubhie Panicker <pani...@chromium.org> wrote:

Thanks for the Intent and the details Kinuko!

We do want to provide a way for the sites / such usages to opt-out this behavior, maybe *any* background throttling. (Discussion is still in-progress and we're not fully settled on this one yet)

This seems like the main issue to sort out as part of the I2S:

• Is the opt-out necessary (assuming developer opt-out)? 
• Is it a temporary or permanent opt-out? 
• Does it need to be developer controlled (eg origin trial) or would we maintain our own internal database of opted out origins?
  

Re: using more general background opt-out, it's unclear how it fits there:

• For background throttling (in general) there isn't any long term developer opt-out planned, only user opt-out eg. for worker throttling.
• For background freezing / discarding - the plan is to have a temporary developer opt-outs during the rollout and until relevant APIs become available.

Perhaps the following Qs might help understand the need for opt-out better:

- Which enterprise use-cases are adversely affected?

- What alternatives (eg. addition of grace time etc) have been considered to help these cases rather than full opt-out?

Yep I agree that these should be clarified.  To make the part clearer: our (or my) current thinking is that providing a user opt-out flag that can be also configured by enterprise policies can be useful and seems to make sense, while we are not yet sure for developer opt-out options for now either.  That means that we have no plan for the latter (i.e. developer opt-out) for now, at least until we have convincing use case or data that make us think such option is useful on the Web.  (And now that I wrote out these explicitly I suppose people can chime in if anyone has strong thoughts)