Better handle animated images

[yoavweiss]

Currently for animated images we report a paint time that corresponds to the time the last frame was painted.
It seems more accurate to report the paint time of the first complete frame for them, potentially as a separate attribute.

A few questions:

• Should we replace the current paint time or report "animated first frame time" as a new attribute?
  • Not doing that would violate the assumpation that load time is smaller than paint time, and can increase confusion.
• When should we report entries for such images? Should we report them before load time is done?
  • This can be meaningful for large animated images, or if we extend this to auto-playing videos.
• Should we change the startTime for animated images to account for the first frame?

[yoavweiss]

Another point worth considering for both animated images and videos (#88):
We won't be able to expose the LCP time (the time the first frame rendered) for cross-origin images without an opt-in, as that would expose information about the image's content. Beyond that, we need to think if this is something that should be gated by TAO, or needs stronger/different opt-ins, such as CORP or even CORS.

[yoavweiss]

In conversations with @npm1, we realized that it may be problematic to have the entries wait until loadTime to be emitted, for a couple of reasons:

• Current LCP processing code may rely on the order of the candidate entries to assume their relative positioning - later entries represent later candidates. Firing animated image after loadTime, but significantly after their first paint time could throw off such code, and make it reach the wrong conclusions regarding which candidate is the latest/largest.
• In the cross-origin case, loadTime can be misleading and can have huge discrepencies with the "first frame paint time".

While it's easy to omit loadTime in such cases, there's the question of what should be the startTime in the cross-origin case of animated images. Should it be the time the entry was emitted? Can we even emit the entry without an opt-in of some sort?

[yoavweiss]

One thing we could do to avoid having the fact that the entry is emitted at all expose new information, is to delay any future other entries from being emitted until the animated image reaches onload, and only emit the animated image entry then. That way we can maintain the order of LCP entries being emitted, without exposing new info.

[npm1]

That is certainly possible, although that also has downsides. If the image never finishes loading in many page loads, the LCP detected by the developer will be incorrect: either an earlier LCP or no LCP. But you pose a good point: the time in which the entry is emitted is presumably close to the render time, so even exposing that one might not be ok. But if we keep using that logic, even exposing the fact that the entry was created could be somewhat problematic, as the delay to receive the entry would leak some information about the time it takes for the entry to be ready to be dispatched, which is essentially the render time we're trying to not expose without some safety check.