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

[Maciej Stachowiak]

> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> 
> 
> On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:
> 
> 
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal <noam.j.rosenthal at gmail.com <mailto:noam.j.rosenthal at gmail.com>> wrote:
>> 
>> 
>> 
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:
>> 
>> Some quick comments: 
>> 
>> the definition of First Contentful Paint here in the spec: <https://www.w3.org/TR/paint-timing/#sec-terminology <https://www.w3.org/TR/paint-timing/#sec-terminology>> does not match the definition stated at <https://web.dev/first-contentful-paint/ <https://web.dev/first-contentful-paint/>>. The Chrome definition on web.dev <http://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?
>> The draft version of the spec specifies that iframe content is not included in FCP:  https://w3c.github.io/paint-timing/#sec-reporting-paint-timing <https://w3c.github.io/paint-timing/#sec-reporting-paint-timing>, and has a few more comprehensive details about this. I think it's a good place to start.
>> 
>> 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?
>> No, this has not been implemented in Gecko, I'm tracking the bug on this: https://bugzilla.mozilla.org/show_bug.cgi?id=1518999 <https://bugzilla.mozilla.org/show_bug.cgi?id=1518999>, there was some movement recently.
>> 
>> I suggest to start from "first-paint", and to try to match chrome as much as possible in how FCP is implemented, in the cases where the spec doesn't give enough detail, if such places exist. I think that for the main use-case of catching regressions for website code, it's ok (and almost unpreventable) if the implementations have some variances between them, what matters is that the metric is reliable for the particular browser. 
>> I also suggest to start with "first-paint" as it's perhaps a bit less "internal" than FCP, and can provide a performance-regression metric with a lesser degree of risk regarding exposing internals / privacy.
> 
> First paint that’s not first meaningful/contentful paint is not a very good performance metric IMO. Who cares that a paint happened if it doesn’t have any image or text content?
> 
> I also don’t think this exposes less. The privacy risk here is exposing timing data that might be usable for fingerprinting.
> 
>>  
>> 
>> 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.
>> What was deprecated was "first meaningful paint" (FMP). FCP was not deprecated and has been in wide use for some time.
> 
> What’s the difference between First Meaningful and First Contentful?
> 
> There is no difference in Safari because we don't do any painting of a newly navigated until the first meaningful paint happens.

WebKit’s notion of First Meaningful Paint is not the same as Chrome’s, from the sound of it. It sounds closer to Chrome’s First Contentful Paint, which makes no attempt to exclude sidebars or navigation bars or the like. (But it does exclude iframe).

> 
> - R. Niwa
> 
>> 
>> Finally, we should do a privacy review to consider whether exposing this info to webpages creates fingerprinting risk or otherwise exposes user data.
>> Great, what is needed for such review?
> 
> We will discuss with Apple’s privacy experts what they think of the privacy risk. I’m just giving you a rain check for results of this discussion.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <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/602c613c/attachment.htm>