Gather scheduling strawman about lighthouse HOT 5 CLOSED

I like it. How do we guarantee ordering? (You could put at rest before initial), and how do we order within the set of gathers scheduled for a given lifecycle point? Last question: who instructs the driver to move to the next stage?

from lighthouse.

I am pretty convinced that some gather operations will be destructive (cause the browser to be in a state where no other gathers can run)

For now, allowing the gather to do whatever will continue to work, I think this is a deep deep rabbit hole if we start trying to optimize the gather phase. I am totally with you that the more times we revisit the page the more variance we will get (if we gather the same number twice) But I am not so convinced of the upside of trying to optimize the gather phase to reduce the number of reloads given the complexity cost of this task.

So long as each gather phase exits cleanly everything should be "OK"

For drool, i setup basic life-cycle hooks that you could put logic in for each memory test, that seemed to work out pretty OK for me.

https://github.com/samccone/drool/blob/master/docs/api.md#flow

from lighthouse.

Tried to capture a few usecase for timing in this doc: https://v.etherpad.org/p/MCiOMkGOcf

@deepanjanroy was thinking it may make more sense to have gathers extend a base class that has these lifecycle events defined.. e.g. setup, beforeLoaded, pageLoaded, teardown.

This is in line with how Telemetry does it, in fact. In key_silk_cases.py see __init__, RunNavigateSteps, RunPageInteractions PerformPageInteractions

from lighthouse.

There's already a gather base class IIRC so we should be gtg there.

from lighthouse.

Yyyyyyyeah https://github.com/GoogleChrome/lighthouse/blob/master/gatherers/gather.js

from lighthouse.