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.

[Shubhie Panicker]

-blink-dev

Hey all

What's the status of this experiment? 

Looks like shipping in M66(?), is there a link to Intent to Ship (I couldn't find it), would love to see the metrics etc. (as a point of comparison for our other background interventions).

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

[Kinuko Yasuda]

We're in the middle of trying to enable this by default, but having some regressions and going back and forth with the experiment flag.  We didn't go through public Intent-to-ship process because this shouldn't have a visible Web-surface changes (other than that the background tabs appear slower) but only went through internal release process-- but thanks for reminding that we haven't followed-up the Intent-to-implement thread yet.

Rough raw results from the last checkpoint was something like:

On m64 stable, we are seeing statistically significant improvements on loading metrics:
* About 3-4% improvements of loading metrics, {Navigation|Foreground}ToFirst{Contentful|Meaningful}Paint
* Compared to the last time, we have tuned the behavior so that subframes can be throttled more than main frame which explains the improvements.

 

On m65 beta, we added more targeted metrics and started seeing bigger improvements. While not statistically significant yet, here is what we consistently see on the loading metrics:
* Loading 3+ tabs: ~6% improvements
* Loading 5+ tabs: ~12% improvements

Takashi (toyoshim@) has been making some doc summarizing the experiment result too, I think we can share that on this thread too but once we make sure the flag can really stick. (Let me also note that Takashi's about to go on parental leave so it may not come too soon, but I can try to share whatever I can, feel free to ping me)

​

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

--

Takashi Toyoshima
Software Engineer, Google

--
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.