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

[Ryosuke Niwa]

On Wed, Feb 26, 2020 at 9:00 PM Maciej Stachowiak <mjs at apple.com> wrote:

>
>
> 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> wrote:
>
>>
>>
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal <noam.j.rosenthal at gmail.com>
>> wrote:
>>
>>
>>
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <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> 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?
>>>
>> 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, 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, 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).
>

Well, WebKit does have heuristics like the number of characters that have
been laid out to gate the initial paint whereas Blink makes no such
attempts for having the first contentful paint (it just means the painted
content has something more than pure white / blank tile).

Note (for folks not familiar with WebKit's navigation / painting model)
that, by definition, WebKit's first painting of a newly navigated page *is*
the first contentful paint and also the first paint because we never even
attempt to paint the page until then (if we did paint the newly navigated
page prior to that point, that'd be considered as a bug).

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