Lighthouse: LH wait for user-fired event on load

[aliry]

I'm making automation perf tests using LH.
I've noticed LH is closing the browser as soon as load event is fired.
However, in my case I'm passing some url parameters which are design to perform some action after page is loaded inside the page. Its important for us to measure those actions performance.

Is there any way to setup LH to continue running and wait for a custom event before closing?

[wardpeet]

At the moment we have no solution for this if not mistaken. You could always create a gatherer that waits for a specific event but it has to be in 30 seconds

[aliry]

is the 30 second max hard coded or is configurable?

[benschwarz]

There’s a flag for max wait time 👍
Check the cli help for more info

[wardpeet]

you could indeed use --max-wait-for-load= which is calculated in ms so 30s = 30000

[aliry]

I know about--max-wait-for-load but its not solving this issue
As I've mentioned above I need LH to keep working even after load event fired for the webapp to perform additional tasks which we need to measure performance.
I need either some kind of wait-for-event to tell LH to stop after given event fired or stop-after-ms to stop LH after given time instead of listening for load event.

[benschwarz]

@aliry It's not obvious from the flags, or without looking into the source, but lighthouse doesn't actually use onLoad directly—Lighthouse waits for network activity to reach an 'idle' state before it stops a test run. ("Idle" is currently described as < 2 active requests)

If your site never has a period of quiet network, then it's likely that you're hitting the "max-wait-for-load" time.

Perhaps you can create a custom configuration to change the network idle settings? (See this line in default.json to see what I'm referring to)

[patrickhulce]

@aliry Ben's tip on custom configuration should work for you. The pauseAfterLoadMs is the number of milliseconds LH will wait after the load event before continuing and calling the afterPass methods of the gatherers. We wait for this and network idle as Ben described.

https://github.com/GoogleChrome/lighthouse/blob/04b685fa9f492039ba54d60bbfaa8345c85c64dd/lighthouse-core/config/default.js#L15-L17

[aliry]

can anyone point me to the place in the code that LH is waiting for network idle state?
I think the best thing for me is to fork it and introduce a new handler to wait for an event to fire.
because in my case the website might even have network idle state at some point and I dont want to increase networkQuietThresholdMs also since it might cause problem with periodic network calls that the web app is doing as handshake to the server to keep the current user session active.

I think we need a clear way for the website to tell the LH its now the right time to stop tests.

[aliry]

Here is the custom config I'm using

module.exports = {
passes: [{
recordTrace: true,
pauseAfterLoadMs: 50000,
networkQuietThresholdMs: 50000,
cpuQuietThresholdMs: 50000,
useThrottling: false,
gatherers: [],
}],
audits: [
'first-meaningful-paint',
'speed-index-metric',
'estimated-input-latency',
'first-interactive',
'consistently-interactive',
]
};

With these settings I was hoping to see LH to run minimum for 50 seconds. But it always stops after about 20 seconds regardless of what ever value I put on these variables.

[patrickhulce]

@aliry have you also increased the maxWaitForLoad in the flags? it will stop at 30s by default no matter what you put in here unless you increase the maximum timeout as well.

[aliry]

Thanks everyone for all the tips.
It finally worked after increasing the maxWaitForLoad as well as pauseAfterLoadMs, networkQuietThresholdMs and cpuQuietThresholdMs

Although in general it doesn't seem to be very robust way of controlling the automation test flow. since increasing these thresholds more than what it actually needed might affect the results accuracy. plus for different test cases and environments these values might defer.

I wish LH had some other option to stop tests on an event or some other handler which the test runner had control on it.

[patrickhulce]

Thanks for the suggestion 👍 this work is also necessary for increasing the accuracy of some metrics, so we'll likely be addressing it at some point in the future.