Q3 plans for Time To Interactive?

[Kenji Baheux]

bcc: loading-dev, progressive-web-metrics as an FYI

Hi Input-dev!

The Loading team is considering an OKR to help on Time To Interactive (TTI) and other input-dev related metrics if relevant.

We're assuming that TTI will be on your Q3 plans. Here is our tentative OKR:

Integrate Time-to-interactive (TTI) to loading measurement infra

Owners: kenjibaheux, kinuko, kouhei, ksakamoto

• +0.4 Keep tracking the progress of impl (to be done by input-dev) --> need to make sure where the actual code is, what their plan / timeline will be
  
• +0.4 Integrate it to PageCyclerV2
  
• +0.2 UMA*
  

Let us know what your plans are for PWMs and where you would need help from the loading team.

Best,

*: I'm not sure what was meant by +0.2 UMA: I'm assuming that the input-dev team would actually own this part.

[Timothy Dresser]

A main thread responsiveness metric is in our OKRs.
"Progressive Web Metric for input responsiveness landed in at least 1 form."

In addition to a dependency on the main thread responsiveness metric, TTI has dependencies on information which will be provided by the loading team, and I believe we established that the code for computing TTI would live with the code for computing other metrics owned by the loading team.

The input team will be responsible for exposing a signal for main thread responsiveness which would be consumed by that component (PageLoadMetricsObserver).

I think it makes more sense to view the input-dev work as a dependency of TTI, but have the loading team drive the TTI specific work.

When presenting this metric, we want it to be presented identically to FCP and FMP, so I think having a consistent team drive the presentation of this set of metrics makes sense.

The progressive web metrics tracking doc currently doesn't list an owner for this metric - we should work on figuring out who should drive this.

Tim

[Kinuko Yasuda]

Hi Tim,

Your plan makes a lot sense to me too.  I think Sakamoto-san (and Kouhei) can drive this work from loading team.  (Bryan-- if there's any misunderstanding between us pls ping)

A few questions-- how would we be able to track the work?  Maybe you could start cc-ing ksakamoto@ to your crbug and CL so that he can start thinking about how loading team could work on top of it?  Do you have ETA for landing it (in at least 1 form)?  Depending on the timeline and how the dependency comes out we probably want to adjust loading team's Q3 OKR items.

[Tim Dresser]

Patch in progress for measuring main thread responsiveness here.

Bug here.

I've cc'ed ksakamoto@ on both.

The current patch is measuring the average input latency - in a followup patch, I'll add measuring percentiles of input latency. I'm hoping to land the current patch this week, which should at least be good enough to base an implementation on. If we decide to change the precise definition of when we consider the main thread responsive, that shouldn't impact your changes much, if at all.

+Brendan Kenny +Paul Irish 

I think the next step is to go over the doc describing TTI carefully, and figure out the exact approach we're going with.

Tim

[Bryan McQuade]

This all sounds great thanks!

[Kinuko Yasuda]

Thanks Tim!

On Tue, Jul 5, 2016 at 10:41 PM, Bryan McQuade <bmcq...@chromium.org> wrote:

This all sounds great thanks!

On Tue, Jul 5, 2016, 8:59 AM Tim Dresser <tdre...@google.com> wrote:

Patch in progress for measuring main thread responsiveness here.

Bug here.

I've cc'ed ksakamoto@ on both.

The current patch is measuring the average input latency - in a followup patch, I'll add measuring percentiles of input latency. I'm hoping to land the current patch this week, which should at least be good enough to base an implementation on. If we decide to change the precise definition of when we consider the main thread responsive, that shouldn't impact your changes much, if at all.

+Brendan Kenny +Paul Irish 

I think the next step is to go over the doc describing TTI carefully, and figure out the exact approach we're going with.

Yep, +1.  We'll adjust our OKR accordingly too.

[Tim Dresser]

+chrome-progres...@google.com for context.

[Tim Dresser]

In the progressive web metrics meeting yesterday, it sounded like there was some confusion over ownership here.

If I understand correctly, the plan for Q3 is:

• input-dev provides a signal that the page is interactive.
• loading-dev will plumb up the actual TTI metric.

Does that sound reasonable? We've scaled down the first prototype for TTI - we're thinking the first thing we land will be:

• The page is interactive if we're in a time window with duration > 10s which contains no tasks > 50ms long
• We fire TTI the first moment the page is interactive after FMP

Does this sound reasonable?

The TTI metric doc now reflects this simpler model, with some of the more complex ideas for future exploration in the Alternatives section. 

[Kunihiko Sakamoto]

Thanks for the clarifications. These sound reasonable to me.

A few questions:

• Is the tracking bug http://crbug.com/607151 ? I'm a bit confused as it does not mention about TTI.
  
• What the signal interface will look like?
  
• Looks like we need to give FMP as an input? This could be a little tricky, as FMP is not a real-time metric; it can't be reported until network activity settles down.
  

Kunihiko Sakamoto

[Bryan McQuade]

Ah, interesting challenge re: FMP. Could we see if using FCP would work here in the meantime?

[Ned]

https://bugs.chromium.org/p/chromium/issues/detail?id=630300 is the tracking bug for implementing TimeToInteractive in TBM2 metrics framework. I believe that this phase don't require real-time metric yet.

--
You received this message because you are subscribed to the Google Groups "chrome-progressive-web-metrics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-progressive-we...@google.com.
To post to this group, send email to chrome-progress...@google.com.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/chrome-progressive-web-metrics/CAO5vZCg%2Bcm7dNOyp_Xeqp571hFO_WtvE-wFB69uyje0TzKEQ1g%40mail.gmail.com.

[Tim Dresser]

We didn't have a high level tracking bug - I've created one here.

I think we can still make FMP work for the UMA case, but the interface that the input pipeline uses to signal when the page is interactive will need to be somewhat different from what I was originally thinking. 

I've roughly outlined one possible approach to computing this online in the TTI doc here.

There will be some edge cases, but I think we can make something along those lines work.

Who will own the loading-dev portion of this effort?

[Kunihiko Sakamoto]

Yeah I think the approach described in the doc will work.

I will own the loading-dev portion.

Thanks!

Kunihiko Sakamoto