Intent to Prototype: LCP support for animated images/auto-playing videos

39 views
Skip to first unread message

Yoav Weiss

unread,
Oct 25, 2021, 4:45:54 AM10/25/21
to blink-dev

Contact emails

yoav...@chromium.org

Explainer

LCP (Largest-Contentful-Paint) is a visual loading metric that measures the time it took for the largest contentful element to be painted on the screen. Right now, LCP measures the paint time for the image's last paint, regardless of whether the image is animated. It also ignores auto-playing videos as LCP candidates. 


This intent proposes to include paint time of the first frame in same-origin or Timing-Allow-Origin enabled animated images in LCP candidate entries, as well as expose videos similarly.

Specification

Issue: https://github.com/WICG/largest-contentful-paint/issues/83

The issue hasn't yet been thoroughly discussed, and the API shape is not necessarily final. Prototyping the approach would allow us to assess feasibility and impact on the metric, as well as gather feedback on the API shape.

Summary

Expose animated images and auto-playing videos' first frame paint time in LCP candidates.



Blink component

Blink

Motivation

LCP currently mis-reports animated images and ignores auto-playing videos. Having LCP better account for those images would better align the metric with user-experience.



Initial public proposal

https://github.com/WICG/largest-contentful-paint/issues/83


TAG review

Exposing an extra timestamp on an already existing LCP entry doesn't seem to require bothering the TAG with. Happy to send an FYI or a full TAG review if y'all think differently.



TAG review status

Not sent

Risks



Interoperability and Compatibility


Currently LCP is not implemented in neither Gecko nor WebKit. I don't believe this extra timestamp increases interoperability risk on that front.
In terms of compatibility, the plan is to measure the impact of this change. As currently exposed this change is purely additive, and doesn't impact currently exposed timestamps.
One of the conclusions of prototyping and experimentation may be that we need to expose this timestamp as the `startTime`. If we take that route, we can discuss the risks involved at that point.



Gecko: No signal

WebKit: No signal

Web developers: No signals


I'm planning to discuss this at the upcoming WebPerfWG TPAC meeting, to gather opinions from both developers and other vendors.


Debuggability



Is this feature fully tested by web-platform-tests?

Yes: https://chromium-review.googlesource.com/c/chromium/src/+/3226157 

Flag name

The feature is covered by 2 flags:

blink::features::kLCPAnimatedImagesReporting - exposes the timestamp to PageLoad metric reporting, but not to the web.

LCPAnimatedImagesWebExposed - a RuntimeEnabled flag to expose the feature to the web.

Requires code in //chrome?

Nope

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1260953 

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status



The intent message was not generated by Chrome Platform Status, as it doesn't have an I2P generator for "web-developer facing changes to existing code".
Reply all
Reply to author
Forward
0 new messages