polish: listen for network idle after DCL

[patrickhulce]

@brendankenny has observed flakiness of TTCI and TTFI on simpler sites since we've switched to waiting on 2-quiet, my hypothesis is that under the new harsher throttling, we'll see this even more frequently because 2-idle is true as soon as we request the initial page (which if it takes too long 2-quiet could fire before we even load any other content!). Worst case sites already run up to the timeout, so this shouldn't impact them as much. Simpler sites see longer times, but that's the goal since we're ending the trace too early in some cases.

UPDATE: waits for DCL before listening for network idle per @deepanjanroy 's suggestion, this seems to mostly fix the issue for sites like vevo and NASA who were reaching "network idle" while the primary script request was in-flight

[brendankenny]

#2238 might throw another wrench in the works as well :)

I can do some testing with both this afternoon.

https://react-hn.appspot.com/ was a common flaky test site if others want to try some things out.

[tdresser]

@deepanjanroy FYI.

[deepanjanroy]

I don't know if this is an urgent fix for I/O so maybe you shouldn't block this change, but many many sites do long polling / intermittent polling and they may never hit network quiet if we use 0-quiet. Technically you're supposed to wait after FMP, but our current definition of FMP also needs a quietness condition so I can see there is a circular dependency here.

Could we wait for FCP/DCL before looking for network 2-quiet? Would that fix the issue?

[deepanjanroy]

Or maybe I'm not understanding how lighthouse works - is there a hard timeout?

[patrickhulce]

@tdresser @deepanjanroy FWIW the signals we used before weren't quite as sophisticated since we don't actually get live network quietness (protocol events are delayed while there's main thread activity). This shouldn't be a problem once we have the quietness signal from Chrome plumbed through and can just listen for it over the protocol. We took a shortcut in #2220 to try to get the run time down.

Could we wait for FCP/DCL before looking for network 2-quiet? Would that fix the issue?

waiting for DCL before kicking off our 2-quiet 5s window would probably fix this too it just wasn't part of the "it worked before" fix :) I'll compare some times with that and the old (current PR) approach

[deepanjanroy]

Oh I see - I was missing a lot of context on this PR. Thanks for clarifying :)

[patrickhulce]

updated to just wait for DCL instead PTAL @brendankenny :)

[patrickhulce]

⛰

[brendankenny]

2Fast4DCL

[brendankenny]

LGTM.

I do wish we had monitoring set up for tracking general failure rates (for whatever metric). This should only push out end of trace, though, so it should only help things (at the expense of sometimes tracing too long).