Lighthouse doesn't wait long enough for page to load (NO_LCP)

[eduardosada]

Steps to reproduce

1. Run lighthouse https://clientes-bancocaminos.grupocaminos.es
2. Open report

What is the current behavior?

On CLI I get:
largest-contentful-paint:warn Caught exception: NO_LCP

On DevTools I get:
Largest Contentful Paint Error!
Something went wrong with recording the trace over your page load. Please run Lighthouse again. (NO_LCP)

What is the expected behavior?

I don't expect any errors.

Environment Information

• Affected Channels: CLI, DevTools
• Lighthouse version: 6.1.1
• Chrome version: 84.0.4147.105

[patrickhulce]

Thanks for filing @eduardosada! I'm not able to reproduce this issue though :/

Any other steps or information you can give us that might help?

[eduardosada]

I just tried web.dev/measure and sometimes it works and sometimes it doesn't.

https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fclientes-bancocaminos.grupocaminos.es%2F

¿could you please try again a couple of times? I think it could be a race condition.

[patrickhulce]

Ah thanks for the example report, in that case it looks like Lighthouse did not wait long enough for the page to completely finish. You can control this from the CLI with the networkQuietThresholdMs in a custom config, but we should try to wait long enough for LCP at least too.

[patrickhulce]

Action items here:

• Add an extra waitForLCP in driver (similar to waitForFCP)
• Make networkQuietThresholdMs configurable from CLI?

[adamraine]

Would adding a _waitForLcp make _waitForFcp redundant? Can there be a situation where Chrome records LCP but not FCP?

[patrickhulce]

Would adding a _waitForLcp make _waitForFcp redundant?

From the technical page load perspective yes but lighthouse treats FCP specially so we'll probably still want both for two main reasons.

1. We want the thresholds for each to be very different (FCP on order of ~15s whereas LCP should be close to maxWaitForLoad)
2. Failure of FCP means the entire run fails whereas LCP missing only fails a few audits.

[connorjclark]

@patrickhulce should we hold this until after fraggle rock?

[patrickhulce]

I wouldn't delay it just for fraggle rock. The waitForX is all gonna be reusable logic for the most part. It might get a long overdue refactor out of driver as part of FR, but that shouldn't stop us :)

[patrickhulce]

Another aspect we'll want to consider when we pick this work back up is waiting for all images with a high priority (signal for above the fold) to finish loading for LCP as well. The test case for this is a page with a single very large image that takes more than our quiet timeouts to load.

[adamraine]

Chromium issue https://bugs.chromium.org/p/chromium/issues/detail?id=1126129