Offscreen elements should be considered once they enter the viewport?

[patrickhulce]

There are real world pages that animate in all of their content with a transition such that LCP can never be computed.

I understand it's computationally far more difficult, but being able to consider offscreen elements that enter the viewport would help the metric be more inline with end user perception of content rendering time.

Minimal example: https://melodic-class.glitch.me/lcp-animate-offscreen.html

Originally filed at https://github.com/GoogleChrome/lighthouse/issues/10869

[npm1]

For the minimal example, one possible solution could be to just use the first nonzero size (at least I can't tell whether the content animates in smoothly, I see the full text). This would be an easy fix modulo performance regressions from having to compute intersection rects of offscreen content every time.

For the real world page this might be insufficient. The animated text may be only halfway into the screen at the time it is first visible, hence the computed size would be wrong. Therefore, we'd need to detect that the text is being animated. And then we'd need to wait for the animation to end, but then you could imagine some site with content (maybe think about an image) bouncing up and down the screen. So in these cases the animation never finishes, so that would be insufficient to determine that LCP is reached, and hence we might want to wait to see if the content becomes fully onscreen. But again, this may never happen... And you see we're getting into a rabbit-hole here.

That said, I do appreciate the problem that LCP is inaccurate for that site, so maybe we can think of some simple imperfect way to determine when offscreen content is settled into the screen. For instance my idea of looking at whether the size is 0 is simple and it might produce the correct LCP for the real-world example (incorrect size though, and the LCP would be slightly earlier than what I'd consider the correct timestamp), although I do worry about performance here.

Sorry for the rambling here. I hope it makes some sense. What do you think?

[patrickhulce]

This would be an easy fix modulo performance regressions from having to compute intersection rects of offscreen content every time.

IMO this would be a huge improvement over getting nothing at all 👍 The page in question would have a roughly accurate picture of when its content started animating in at the very least.

The animated text may be only halfway into the screen at the time it is first visible, hence the computed size would be wrong.

Would the first two consecutive, equivalent non-zero sizes work for this problem or still just as bad perf-wise as waiting for animations to end? Naively I'm thinking if an image is animating around but its size is the same you can stop tracking it very early on.

[npm1]

Would the first two consecutive, equivalent non-zero sizes work for this problem or still just as bad perf-wise as waiting for animations to end? Naively I'm thinking if an image is animating around but its size is the same you can stop tracking it very early on.

That's an interesting idea, but that would also mean storing these sizes for every object so that they can be compared on subsequent frames. We do this right now but it wouldn't be necessary on LCP when removed nodes are considered valid candidates.

[yoavweiss]

Looks like this requires some more thoughts and/or research. The issue awaits someone to pick up this task.

/cc @clelland @anniesullie

[mmocny]

Does anyone know what happens with automatic scroll restoration?

I know we halt LCP on user driven scroll, but what about automatic browser driven scroll (i.e. back button or fragment navigation)... could off below-the-fold elements become LCP in those cases? If so, would measurement depend on the ordering of their load relative to scroll restore?

(I'm finding it hard to create a quick test that gives a reliable result)