core(preload-lcp-image): fix faulty request chain exclusion logic

[connorjclark]

ref #14300 (comment)

[connorjclark]

This delta here shows the new logic is WAI, as this image is directly requested by the main document.

https://www.mikescerealshack.co/corrections

[brendankenny]

For the smoke failure: added an additional issue to #14300 (comment) that I believe has come up in the past but I couldn't find written down anywhere. A dynamically-loaded image with img.loading = 'lazy' set on it will lose the networkRequest initiator information, but lantern will try to recover and still at least include it connected to the root request.

That's what's causing the test to think that it was a single hop from html->image even though it's actually delayed-element.js adding the image to the page (the imgEl.loading = 'lazy'; line was added later when the lcp-lazy-loaded audit was added).

[connorjclark]

Should we just mark this audit n/a if the LCP element initiatorRequest is undefined, and just 100% defer to lcp-lazy-loaded?

[adamraine]

Is this +1 for the redirect request? What if there are multiple redirects?

[connorjclark]

No, this is addressing the first bullet point of #14300. The mainResourceDepth variable accounts for the redirects.

[brendankenny]

Should we just mark this audit n/a if the LCP element initiatorRequest is undefined, and just 100% defer to lcp-lazy-loaded?

Should it be a warning instead? I'm not sure how often and in what circumstances Chrome loses initiator info, but

• it would be nice to query that via HTTP Archive, and
• n/a kind of lets the site off the hook. At least for lazy loading, (AFAIK) the only way for this to happen is for the image to be added by JS, so we know it's at least not discoverable in the main document, we just can't calculate the opportunity.

[connorjclark]

@brendankenny should I be doing something else here?