Design doc: Throttling delayable requests in the presence of non-delayable requests.

[devde...@chromium.org]

Contact

devde...@chromium.org

tba...@chromium.org

Summary

This is a proposal for an experiment to analyze the effects on page load metrics of throttling delayable requests in the presence of non-delayable requests in-flight.

Tracking bug
746640

Design doc

https://docs.google.com/document/d/1pg5B4WoNfr1x2P9Xa3nfp4ggGNMBNnVjFxAGKbOhnDA/edit?usp=sharing

[tba...@chromium.org]

I recently got the chance to complete the data analysis for this experiment. Here are the results. Comments are welcome.

[Takashi Toyoshima]

Thank you for sharing results.

Do you have a next plan?

I think current design will not work if the network service is enabled, anyway.

In most cases, Chrome does single page loading rather than multiple-page loading, and it implies that if this works in general, it may work even if the same logic runs per-page in renderers side.

Currently, ResourceLoadScheduler does not count ECT in, but it would be possible to adjust thresholds adaptively based on ECT.

--
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/a7f56714-c7b4-4fad-8fde-0895650dadc4%40chromium.org.

--

Takashi Toyoshima
Software Engineer, Google

[tba...@google.com]

On Wednesday, March 7, 2018 at 9:56:18 PM UTC-8, Takashi Toyoshima wrote:

Thank you for sharing results.

Do you have a next plan?

I think current design will not work if the network service is enabled, anyway.

In most cases, Chrome does single page loading rather than multiple-page loading, and it implies that if this works in general, it may work even if the same logic runs per-page in renderers side.

Currently, ResourceLoadScheduler does not count ECT in, but it would be possible to adjust thresholds adaptively based on ECT.

Kinuko's doc on scheduler servicification covered some of this. And, yes, the plan is to move some of the logic to ResourceLoadScheduler in renderer where we can adjust the request count based on network capacity and the page state (e.g., whether the first paint or commit has happened).

I also talked with yhirano@ about this. Right now, yhirano@ is only moving the |has_deprecated_body_| from the content resource scheduler to the renderer side. The current design of adjusting the request count based on network capacity in content layer is compatible with that change. Once there is more progress in scheduler servicification, it should be possible to move the network capacity based logic to ResourceLoadScheduler.

 

On Wed, Mar 7, 2018 at 3:38 AM, <tba...@chromium.org> wrote:

I recently got the chance to complete the data analysis for this experiment. Here are the results. Comments are welcome.

On Tuesday, August 1, 2017 at 2:17:18 PM UTC-7, devde...@chromium.org wrote:

Contact

devde...@chromium.org

tba...@chromium.org

Summary

This is a proposal for an experiment to analyze the effects on page load metrics of throttling delayable requests in the presence of non-delayable requests in-flight.

Tracking bug
746640

Design doc

https://docs.google.com/document/d/1pg5B4WoNfr1x2P9Xa3nfp4ggGNMBNnVjFxAGKbOhnDA/edit?usp=sharing

--
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...@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/a7f56714-c7b4-4fad-8fde-0895650dadc4%40chromium.org.