[webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)

[Maciej Stachowiak]

Some quick comments:

I am concerned that the definitions of these paint milestones have engine-dependent assumptions, and some may not be spelled out in the spec.

For example, the definition of First Contentful Paint here in the spec: <https://www.w3.org/TR/paint-timing/#sec-terminology> does not match the definition stated at <https://web.dev/first-contentful-paint/>. The Chrome definition on web.dev specifies that iframe content is not included, the spec does not have this limitation. Would an implementation that matches the spec match Chrome?

I am also not sure this matches the layout milestones that already exist in non-Blink browser engines. Has this spec been implemented in Gecko, for example, to verity that it’s not exposing a concept that only exists in Blink?

Chrome team themselves have been telling web developers that First Contentful Paint is deprecated in favor of Largest Contentful Paint. Should we concerned about this? It seems even harder to define LCP in an engine-independent way.

Finally, we should do a privacy review to consider whether exposing this info to webpages creates fingerprinting risk or otherwise exposes user data.

Regards,
Maciej

> On Feb 26, 2020, at 3:32 AM, Noam Rosenthal <noam at webkit.org> wrote:
> 
> Hola
> I was approached by the Wikimedia foundation to implement the paint timing API for WebKit (yay).
> I think this is a good feature to have for webkit, and I wanted to hear thoughts about it before I begin.
> 
> The feature was enabled in Chrome for quite a while, and is potentially very useful for real user monitoring to see if changes to the code of the website create performance regressions on different browsers.
> We've been using it extensively (on Chrome) when I worked at Wix.com, and always hoped that "some day" it will be available in other browsers.
> 
> I think it's a pretty lean spec and was stable since 2017, and that it fits with the WebKit project goals, by allowing web developers to better optimize their content and catch Safari/WebKit-specific regressions early.
> 
> I would like to get feedback on whether it's a desired feature for WebKit, if there are caveats/pitfalls I should be thinking about, and anything else that's worth mentioning at this point.
> 
> There are of course delicate decisions to be made as to the choice of timing indicator, but I will get to that once we've sorted out the position in general.
> 
> Bug: https://bugs.webkit.org/show_bug.cgi?id=78011 <https://bugs.webkit.org/show_bug.cgi?id=78011>
> Spec: https://www.w3.org/TR/paint-timing/ <https://www.w3.org/TR/paint-timing/>
> 
> Thanks!
> Noam
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200226/b75fdd50/attachment.htm>