search

w3c / largest-contentful-paint

Specification for the LargestContentfulPaint API
https://w3c.github.io/largest-contentful-paint/
Other
88 stars 17 forks source link

LCP appears on the popup after mousemove interaction #50

Closed alekseykulikov closed 4 years ago

alekseykulikov commented 4 years ago

Bug report: LCP appears on the popup after mousemove interaction Steps to reproduce: Visit Treo Demo on a desktop and, without scrolling, hover over charts. We get RUM data where FCP=0.5s and LCP=60s. The largest image is rendered in the popup after many interactions with a page.

Before filing the bug, I reported the issue to speed-metrics-dev@chromium.org and got this comment from @anniesullie:

Right now the specification takes its event types from the event-timing spec, which excludes mousemove. I think this is a case where we definitely see the limitations of using heuristics. We are considering counting images removed from the DOM, which would help a little by limiting LCP to the first popup, but not help a lot. I think the first thing to do is to file a bug on the specification, so we can discuss with the working group.

npm1 commented 4 years ago

Thanks for the report! Yea that is indeed a flaw in the heuristics since we generally consider mousemove to not be input which causes DOM to change. In this case it does do that, but I'm not sure how we can detect this more reliably. Perhaps if a mousemove event handler gets invoked then we should consider that to be an 'important input'? Do you have any thoughts on that?

patrickhulce commented 4 years ago

Perhaps if a mousemove event handler gets invoked then we should consider that to be an 'important input'?

I like this approach though I wonder what the typical ratio of active/passive mousemove listeners is globally. Conceptually the same problem could appear with any of the continuous ignored events too (custom wheel listener changing things as on scroll). Perhaps at the least there could be guidance given to unregistering the observer if you have meaningful mousemove/wheel event handlers?

npm1 commented 4 years ago

More generally, it's possible to conceive a developer-annotated 'end' of the LCP algorithm (which could be used, for instance, on the event handlers mentioned). That being said, if a developer has that much time to work on improving the LCP signal, wouldn't they instead use Element Timing?

patrickhulce commented 4 years ago

That being said, if a developer has that much time to work on improving the LCP signal, wouldn't they instead use Element Timing?

Probably, but I imagine this broader problem could still be very relevant to LCP as other collection layers report it in RUM tooling like CrUX. While I suppose unregistering your own observer won't solve the CrUX problem, it could be relevant to other providers in the RUM space :)

npm1 commented 4 years ago

I suspect CrUX data will not have this problem. So there would be a problem reconciling that data with the Web Perf API data.

patrickhulce commented 4 years ago

I suspect CrUX data will not have this problem.

Oh, that's surprising to me! Is there a technique there for more reliable LCP reporting that could be shared more broadly? How does Chromium know that the LCP event after mousemove should not be considered there but not in PerformanceObserver?

npm1 commented 4 years ago

Oh no I thought this comment was about the other problem of large images that haven't finished loading. Sorry for the confusion. CrUX data will have issues with this too :)

npm1 commented 4 years ago

For now we have no plans to provide the developer with ways to annotate their event so that they're treated differently for LCP. LCP is a heuristic-based metric and as such it's not perfect and there are cases that are not handled correctly like the one in this bug, but we think ignoring mousemoves is necessary and accurate for most websites. So I'm closing this issue for now but let me know if I missed something.