Intent to Implement: Loading Dispatcher v0 - background tab throttling

[Takashi Toyoshima]

Contact emails

{toyoshim, ksakamoto, kinuko}@chromium.org

 

Design doc

Loading Dispatcher - background tab throttling

 

Summary

We proposes to throttle resource loading requests in background tabs.  The throttling mechanism is to be backed by Blink scheduler, and is the first part of Loading Dispatch Infrastructure that unifies the mechanisms to dispatch resource loading requests. See Mindful Loading: Loading Coordination for the underlying motivation as well as a high-level project roadmap and relationship with other throttling efforts.

 

Motivation

As more sites are starting to be built with a large, complex code base that loads richer Web contents, we’re observing that the number of resources a page loads is increasing.  We have discovered that the number of resources severely affects the peak memory usage (and potential OOM risk) and loading performance via various measurements (Part 1, Part 2), which implies that we should put more control on how Chrome makes resource requests.  We also keep hearing that loading experience and user interaction tends to become horrible when multiple tabs are loading in background, which matches with our measurement results.

 

V0’s goal (background tab throttling) should also make loading behavior more aligned with other throttling efforts in Blink.

 

Interoperability and Compatibility Risk

None.

 

Ongoing technical constraints

None.

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

 

OWP launch tracking bug

crbug.com/723233 (not a launch bug)

 

Link to entry on the feature dashboard

None.

 

Requesting approval to ship?

No.  (This wouldn't change any Web-facing behavior in a noticeable way)

--

Takashi Toyoshima
Software Engineer, Google

[Ben Maurer]

Hey guys --

One concern I have here is that often times people load tabs in the background because they want to see them but they are loading slowly. Throttling seems like it could make that worse. We already see lots of negative perf impact from throttling mechanisms in our production data at FB.

The document isn't publicly accessible so I'm not sure what heuristics you guys are thinking about. Would appreciate if you could share that.

-b

On Monday, June 5, 2017 at 7:08:05 AM UTC-7, Takashi Toyoshima wrote:

Contact emails

{toyoshim, ksakamoto, kin...@chromium.org

[Kinuko Yasuda]

On Wed, Jun 7, 2017 at 8:05 AM, Ben Maurer <ben.m...@gmail.com> wrote:

Hey guys --

One concern I have here is that often times people load tabs in the background because they want to see them but they are loading slowly. Throttling seems like it could make that worse. We already see lots of negative perf impact from throttling mechanisms in our production data at FB.

Yeah that's exactly the story we want to keep supporting as much as it doesn't hurt foreground experience too much.  Our first goal is to experiment a few different parameters while keep watching some loading metrics for background cases.  We are also going to add UMA to measure Switch-to-foreground to FMP to measure the visible impact (ideally this should be 0 if it has passed enough time since start-to-load) so that we can understand better the better balance for throttling.

I think we might also be able to try a few variances, like apply modest (or no) throttling until loading reaches a certain point.  (We can't detect FMP or TTI on background page so we'll need some heuristics there though)

 

The document isn't publicly accessible so I'm not sure what heuristics you guys are thinking about. Would appreciate if you could share that.

Sorry, I just made the doc accessible from anyone with link (comment requires @chromium.org).  Reg: specific throttling parameters we'd like to seek for a good balance via multiple experiments (and will update on this list with results)

 

[Kinuko Yasuda]

On Jun 7, 2017 9:04 AM, "Kinuko Yasuda" <kin...@chromium.org> wrote:

On Wed, Jun 7, 2017 at 8:05 AM, Ben Maurer <ben.m...@gmail.com> wrote:

Hey guys --

One concern I have here is that often times people load tabs in the background because they want to see them but they are loading slowly. Throttling seems like it could make that worse. We already see lots of negative perf impact from throttling mechanisms in our production data at FB.

Yeah that's exactly the story we want to keep supporting as much as it doesn't hurt foreground experience too much.  Our first goal is to experiment a few different parameters while keep watching some loading metrics for background cases.  We are also going to add UMA to measure Switch-to-foreground to FMP to measure the visible impact (ideally this should be 0 if it has passed enough time since start-to-load) so that we can understand better the better balance for throttling.

I think we might also be able to try a few variances, like apply modest (or no) throttling until loading reaches a certain point.  (We can't detect FMP or TTI on background page so we'll need some heuristics there though)

Sorry this was probably opposite, rather we could possibly consider unthrottling (or making throttling less aggressive) once foreground page reaches TTI.

[Takashi Toyoshima]

Hi, Ben

Thank you for your interest. I explicitly add your gmail account to the list who have comment permission though everyone should already have read permission as Kinuko did. (Please ping me if someone outside chromium.org need a comment permission)

One of the scenario we are interested in is reading an article, then opening linked sub contents or external articles in other tabs to read later.

But probably, social sites may have some interesting aspects that I haven't noticed because such sites are more likely to be kept in background tabs. Actually people I know keep some social sites open in background tabs always. But my impression is such site does not fetch so much contents once it reaches to a stable condition, such as TTI.

--
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/CAMWgRNa2kAJOBWzXc0S%2BF8hXDJTfWF3qWEz%3DngQ0mdwWoGKSMg%40mail.gmail.com.