Contact [email protected] ExplainerLCP <https://web.dev/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.
SpecificationIssue: https://github.com/WICG/largest-contentful-paint/issues/83The 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 componentBlink <https://bugs.chromium.org/p/chromium/issues/list?q=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 statusNot 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 <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ?Yes: https://chromium-review.googlesource.com/c/chromium/src/+/3226157 Flag nameThe 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 bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1260953 <https://bugs.chromium.org/p/chromium/issues/detail?id=1260953> Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5693014656679936 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". -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU72Zqedk1Ah2y4mO_jmjDpC2STWQu6bY8jV5o%3Dt4zj%2Bg%40mail.gmail.com.
