core(driver): waitForFCP when tracing #6944

patrickhulce · 2019-01-07T18:16:09Z

Summary
We don't actually wait for an FCP, and it seems like we should. There could be a lot more to this story of making our waitForFullyLoaded match TTI conditions as close as possible, but this is a good start.

Fully Loaded Conditions After This PR

all [load, FCP, network quiet] --> CPU quiet --> done

Potential Easy Alternative

all [FCP, load] --> network quiet --> CPU quiet --> done

Real TTI Conditions

FCP --> simultaneous network + CPU quiet --> done

Related Issues/PRs
closes #6941

paulirish · 2019-01-07T18:35:25Z

node lighthouse-cli/index.js http://localhost:10200/infinite-loop.html --config-path=/home/travis/build/GoogleChrome/lighthouse/lighthouse-cli/test/smokehouse/error-config.js --output-path=smokehouse-19845.report.json --output=json --quiet --port=0 
Runtime error encountered: _waitForLoadEvent.cancel() called before it was defined
Error: _waitForLoadEvent.cancel() called before it was defined
    at Object.cancel (/home/travis/build/GoogleChrome/lighthouse/lighthouse-core/gather/driver.js:182:163)
    at /home/travis/build/GoogleChrome/lighthouse/lighthouse-core/gather/driver.js:236:424
    at Driver._waitForFullyLoaded (/home/travis/build/GoogleChrome/lighthouse/lighthouse-core/gather/driver.js:237:125)
    at <anonymous>

brendankenny

I like the refactor ideas. _waitForFullyLoaded has gotten pretty terrible to read or add to :)

lighthouse-cli/test/fixtures/delayed-fcp.html

lighthouse-core/gather/driver.js

brendankenny · 2019-01-07T21:14:35Z

lighthouse-core/gather/driver.js

@@ -874,23 +918,25 @@ class Driver {
   * possible workaround.
   * Resolves on the url of the loaded page, taking into account any redirects.
   * @param {string} url
-   * @param {{waitForLoad?: boolean, waitForNavigated?: boolean, passContext?: LH.Gatherer.PassContext}} options
+   * @param {{waitForFCP?: boolean, waitForLoad?: boolean, waitForNavigated?: boolean, passContext?: LH.Gatherer.PassContext}} options


is this pulled out as another option for performance reasons, or does fcp not fire in certain passes and we need the option so we don't always wait for the full timeout? It's unfortunate mental overhead since none of the wait* options are independent. Is there a way we can reorganize?

Correcto. On the passes without javascript and offline this can take unnecessarily long when we don't really care about FCP in those passes. In fact, every page that fails the without javascript audit would take 45s+ because all we're doing is checking for the existence of text.

It's unfortunate mental overhead since none of the wait* options are independent. Is there a way we can reorganize?

Agreed. There are really only 4 scenarios despite the 3 total booleans. We could switch to an enum? Opposed to doing it in followup?

There are really only 4 scenarios despite the 3 total booleans. We could switch to an enum? Opposed to doing it in followup?

No, that sounds good. Maybe pair it with a switch to "Potential Easy Alternative" (should mostly match what behavior today) or "Real TTI Conditions" (if we're feeling really brave)

brendankenny

LGTM

Should we do a DZL?

patrickhulce · 2019-01-07T22:47:24Z

Should we do a DZL?

Fo sho

DZL, do a barrel roll!

devtools-bot · 2019-01-07T23:02:13Z

DZL is done! Go check it out http://lh-dzl-6944.surge.sh

brendankenny · 2019-01-08T21:02:23Z

ha, well, I don't know how to interpret the DZL. Two sites slowed significantly in gather time, but the others didn't :) I think that's not unexpected?

One other thing (possibly the cause for the above): for LH runs that end up with the NO_FCP error, we'll now hit the pass timeout while we were probably stopping passes earlier before. That's not a huge deal on the CLI, I don't think (since the results are all audit errors regardless), but might be more of a big deal for LR @paulirish

patrickhulce · 2019-01-08T21:45:34Z

Two sites slowed significantly in gather time, but the others didn't :) I think that's not unexpected?

This is my eternal struggle to get around with DZL for the past month. The comparison hash in that URL was for several days off so the sites were just different 1/4/2019, 8:14:04 PM vs 1/7/2019, 4:48:23 PM. If you take a look at the exact hash from the same day as this was run, you'll find completely different runtime results. I've been doing lots of experiments to figure out how we can get a solid subset, but for now, most runtime results in DZL are pretty much unactionable :(

patrickhulce · 2019-01-08T21:48:16Z

Yes indeed if the page truly never paints content then we will wait until our timeout instead load/network quiet.

but might be more of a big deal for LR

Interesting, just from a capacity point of view? What would the alternative be?

brendankenny · 2019-01-08T21:50:10Z

just from a capacity point of view?

Yeah. I think they were having a bunch of NO_FCP at some point, so the timeout rate might significantly increase in the logs? I have no idea if it would matter, though.

brendankenny · 2019-01-08T22:58:47Z

@exterkamp says it doesn't matter and he'll be happy if he can watch the graphs change a bit :)

@paulirish just concurred.

Ready for merge?

patrickhulce · 2019-01-08T23:35:20Z

baller ⛹️‍♀️

core(driver): waitForFCP when tracing

3a637e8

patrickhulce requested review from brendankenny and paulirish as code owners January 7, 2019 18:16

paulirish approved these changes Jan 7, 2019

View reviewed changes

patrickhulce added 3 commits January 7, 2019 12:45

error msg

ee361aa

oops I thought I reverted this already

cee1040

update appveyor invocation

a276786

brendankenny reviewed Jan 7, 2019

View reviewed changes

patrickhulce added 2 commits January 7, 2019 15:55

feedback

f67917d

another return

a7525e2

brendankenny approved these changes Jan 7, 2019

View reviewed changes

patrickhulce merged commit d5053e4 into master Jan 8, 2019

patrickhulce deleted the wait_for_fcp branch January 8, 2019 23:37

patrickhulce mentioned this pull request Jan 9, 2019

core: INSECURE_DOCUMENT_REQUEST errors still return lhr #6608

Merged

paulirish mentioned this pull request Feb 6, 2019

Increased failures due to 60s timeout on PSI/LR #7174

Closed

patrickhulce restored the wait_for_fcp branch March 2, 2019 17:19

patrickhulce deleted the wait_for_fcp branch April 15, 2019 19:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

core(driver): waitForFCP when tracing #6944

core(driver): waitForFCP when tracing #6944

patrickhulce commented Jan 7, 2019

paulirish commented Jan 7, 2019

brendankenny left a comment

brendankenny Jan 7, 2019

patrickhulce Jan 7, 2019 •

edited

Loading

brendankenny Jan 7, 2019

brendankenny left a comment

patrickhulce commented Jan 7, 2019

devtools-bot commented Jan 7, 2019

brendankenny commented Jan 8, 2019

patrickhulce commented Jan 8, 2019

patrickhulce commented Jan 8, 2019

brendankenny commented Jan 8, 2019

brendankenny commented Jan 8, 2019

patrickhulce commented Jan 8, 2019

core(driver): waitForFCP when tracing #6944

core(driver): waitForFCP when tracing #6944

Conversation

patrickhulce commented Jan 7, 2019

paulirish commented Jan 7, 2019

brendankenny left a comment

Choose a reason for hiding this comment

brendankenny Jan 7, 2019

Choose a reason for hiding this comment

patrickhulce Jan 7, 2019 • edited Loading

Choose a reason for hiding this comment

brendankenny Jan 7, 2019

Choose a reason for hiding this comment

brendankenny left a comment

Choose a reason for hiding this comment

patrickhulce commented Jan 7, 2019

devtools-bot commented Jan 7, 2019

brendankenny commented Jan 8, 2019

patrickhulce commented Jan 8, 2019

patrickhulce commented Jan 8, 2019

brendankenny commented Jan 8, 2019

brendankenny commented Jan 8, 2019

patrickhulce commented Jan 8, 2019

patrickhulce Jan 7, 2019 •

edited

Loading