Intent to intervene: Improved policy for blocking expensive tasks

[Sami Kyostila]

(For background about interventions, see http://bit.ly/user-agent-intervention.)

Contact emails

skyo...@chromium.org, alexc...@chromium.org

Summary

We are proposing to reduce scroll latency by blocking or throttling expensive tasks when user input needs to be processed on the main thread. This is a simplification of our previous policy which blocked tasks during all kinds of gestures instead of just scrolling, which caused breakage on some sites with more complex input event handling.

Motivation

Blocking expensive tasks can significantly reduce the time it takes to process user input on pages with heavy scripts and resources.

Design doc

https://docs.google.com/document/d/14VdbqN-ehgpNC4KYVpPQFiQpfxOQiVtJgYjXUJGI4f0/edit

Tracking bug

crbug.com/574343

All comments welcome!

- Sami

[Timothy Dresser]

Is there an intent to intervene template?

I'd like to see these formatted so that they clearly address each of the points in the interventions doc.

• articulate
  
• The current articulation is fairly clear in the doc, but I'm worried that gesture prediction is opaque enough that this will be confusing for developers. It's possible that the improvement is worth it though.
• specify
  
• Do we have plans to put this in a monkey patch for a spec somewhere?
• guide
  
• The guidelines section is fairly comprehensive, but I'm worried about "For rich cases like this, if the handlers can't be avoided the only option is to ensure all timer tasks adhere to the RAIL performance guidelines." Is "Make your page faster" an acceptable guideline for an intervention? 
• report
  
• Do we have any plans here?
• measure
  
• Do we have any way of approximating the cost of this change? A histogram of how much timers are delayed could be useful here. If we see that some tasks are delayed by massive amounts, that would indicate that something bad is happening.

[Sami Kyostila]

2016-01-15 13:12 GMT+00:00 Timothy Dresser <tdre...@chromium.org>:

Is there an intent to intervene template?

At least I couldn't find one. +Dimitry, maybe we should add it to http://bit.ly/user-agent-intervention?

 

To address your individual points:

I'd like to see these formatted so that they clearly address each of the points in the interventions doc.

• articulate
  
• The current articulation is fairly clear in the doc, but I'm worried that gesture prediction is opaque enough that this will be confusing for developers. It's possible that the improvement is worth it though.

Agreed, maybe a few graphical examples of the prediction would help.

 

• specify
  
• Do we have plans to put this in a monkey patch for a spec somewhere?

It's a bit of a cop-out, but the existing specs for timers are pretty clear that the API doesn't guarantee exact run times. My feeling is that we probably wouldn't want to codify the exact logic for deferring timers as it might change but instead provide reasonable bounds (for the record, the maximum delay from this policy is 2 seconds).

• guide
  
• The guidelines section is fairly comprehensive, but I'm worried about "For rich cases like this, if the handlers can't be avoided the only option is to ensure all timer tasks adhere to the RAIL performance guidelines." Is "Make your page faster" an acceptable guideline for an intervention? 

This is also mentioned in Dimitry's doc, but I don't think we want to simply let people opt out of the intervention; then we'd just be back at square one with a janky website. I feel this isn't very different from other things we already ship which could be called inventions -- such as threaded scrolling. We (and other browsers) made the trade-off that smooth scrolling is more important than the scroll event QoS, and there's (currently) no practical way to opt out.

 

• report
  
• Do we have any plans here?

Yes, that was also (buried) in the doc: initially we're going to emit a console message and a trace event, and later integrate something like http://w3c.github.io/reporting/.

 

• measure
  
• Do we have any way of approximating the cost of this change? A histogram of how much timers are delayed could be useful here. If we see that some tasks are delayed by massive amounts, that would indicate that something bad is happening.

It'd be fairly easy to measure the added delay to timers (nit: <2s instead of "massive"), but that doesn't really tell us anything about the impact to the user. I think the best we can do is make the policy as safe as possible and to make it straightforward for developers to find and report any problems with it.

- Sami

[Dimitri Glazkov]

On Fri, Jan 15, 2016 at 8:01 AM, Sami Kyostila <skyo...@chromium.org> wrote:

2016-01-15 13:12 GMT+00:00 Timothy Dresser <tdre...@chromium.org>:

Is there an intent to intervene template?

At least I couldn't find one. +Dimitry, maybe we should add it to http://bit.ly/user-agent-intervention?

That sounds great. I think your intents are a great start, we should crib from them and mix in Tim's template into them. Early on, when we were just brainstorming this space, Kenji prepared a template, I think?

[Tim Dresser]

Thanks for the clarification Sami!

Launching this behind a finch trial SGTM.

[Philip Jägenstedt]

On Fri, Jan 15, 2016 at 6:03 PM, 'Dimitri Glazkov' via blink-dev <blin...@chromium.org> wrote:

On Fri, Jan 15, 2016 at 8:01 AM, Sami Kyostila <skyo...@chromium.org> wrote:

2016-01-15 13:12 GMT+00:00 Timothy Dresser <tdre...@chromium.org>:

Is there an intent to intervene template?

At least I couldn't find one. +Dimitry, maybe we should add it to http://bit.ly/user-agent-intervention?

That sounds great. I think your intents are a great start, we should crib from them and mix in Tim's template into them. Early on, when we were just brainstorming this space, Kenji prepared a template, I think?

A template would be great, but in the meantime, should we treat "Intent to Intervene" like an "Intent to Implement and Ship" and thus require 3xLGTM?

Philip 

[Dimitri Glazkov]

That's a good question. Should they also be tracked in the spreadsheet?

:DG<

[Rick Byers]

I think there should be some process for approving interventions, and I'm happy to add this to the API owners responsibility if others feel we're a reasonable set of people to do it.  But I could imagine someone making an argument saying that the risk tradeoff profile is different and so decisions should be made with a different (perhaps more aggressive) mindset.

Dimitri, you've talked before about balancing "moving the web forward" with "interoperability and compatibility risk" in the context of shipping new features.  How similar or different do you see that balance being for interventions?

:DG<

[Dimitri Glazkov]

I don't know yet. My intuition is that we should try and see. My proposal is: let's treat it as "intent to ship" for a quarter and then re-evaluate. Thoughts?

:DG<

[Chris Harrelson]

+1 to trying for a quarter. Another reason I think we should do that is that we should start out with interventions that are more conservative before trying anything dangerous, and learn from experience. As a result, it makes sense to apply the same kinds of compatibility concerns that apply to Intents to Ship.

 

:DG<

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

[Alex Komoroske]

Strongly agreed. 

[Sami Kyostila]

Sounds good to me. With that, how is everyone feeling about giving this intervention a try? We're pretty much ready to start a finch trial at this point.

- Sami

[Rick Byers]

Yes, LGTM1 to intervene via a Finch trial!

[Dimitri Glazkov]

LGTM2 too!

[Jochen Eisinger]

lgtm3

[Chris Harrelson]

I also think that all interventions should be required to use a Finch trial and have stated success or failure metrics for this trial. Reasons why:

1. If we can't measure the problem an intervention is solving, then we most likely don't understand it well enough.

2. If we don't perform a controlled experiment, it's likely we don't know if the intervention has any undesired side-effects.

    In addition to the metric the intervention is trying to improve, it's just as important to see what happens to other critical metrics. It's safe to assume that pretty much any intervention *will* have some side-effects we didn't anticipate.

Chris

[Sami Kyostila]

To close the loop here, we first tested this intervention using a Finch trial in M51. Initially the improvements from performance waterfall benchmarks weren’t translating to the real world, but after some investigation we found and corrected issues with the throttling and use case detection logic. After these fixes, UMA from M52 showed the median delay from passive event listeners (i.e., ones that didn't ultimately block scrolling) dropping from 50ms to 30ms. Based on this we decided to launch the intervention in M52.

Details are in the design doc: https://docs.google.com/document/d/14VdbqN-ehgpNC4KYVpPQFiQpfxOQiVtJgYjXUJGI4f0/edit#bookmark=id.bvyxybt4d3xm

- Sami