Detect main thread and network quietness and expose it to devtools |
|||
Issue descriptionTo determine Time to Consistently Interactive [1], we need to keep tracing until we reach network and main thread quiescence, which is currently defined as 5 seconds of no more than 2 network requests and no main thread task longer than 50ms. This is hard to do today because not all devtools network request and main thread task signals are sent as they happen, and even if they were, determining this quiescence requires complex calculations. Since TTCI will be implemented as an UMA and therefore need to detect this quiescence in the browser anyway, we should plumb this quiescence signal all the way to devtools so that devtools and lighthouse can use it as a useful criterion to stop tracing. --- Links [1] https://docs.google.com/document/d/1GGiI9-7KeY3TPqS3YT271upUVimo-XiL5mwWorDUD4c/edit?usp=sharing
,
Apr 24 2017
dproy, I think you already know everything about the motivation here, but if you have any questions, plz holler.
,
May 4 2017
,
Oct 4 2017
,
Jan 15 2018
,
Apr 30 2018
Any update on this?
,
Aug 10
ping from speed metrics triage :)
,
Nov 26
Ping! This bug has been flagged as stale by Chrome Speed Metrics bug triage, and it has an owner. Any update on this issue?
,
Nov 26
Still not done. I've been busy working on Perfetto. It has been assigned to me for an embarrassingly long time at this point; if anyone else wants to take this please feel free. Otherwise I'll eventually get to it. |
|||
►
Sign in to add a comment |
|||
Comment 1 by paulir...@chromium.org
, Apr 24 2017