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

[Ryosuke Niwa]

On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal <noam at webkit.org> wrote:

> (resending from correct address)
> 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 don't think we should do that. For starters, Chrome's painting strategy
while loading a web page is very different from that of Safari / WebKit. We
would freeze the painting of the previous page at the moment a new
navigation is committed, and we wouldn't update the painting until the
destination page has a meaningful content in it. This is a very much
different from Chrome's model where the moment a new navigation is
committed, Chrome will show a blank page then start incrementally painting
the page throughout the navigation.

Second off, the point of specification is to allow multiple independent
implementations. If we had to reverse-engineer what Chrome is doing and
implement that, it defeats the point of having any standard at all.

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.
>

I don't think we don't should that because we don't have an equivalent of
first-paint.

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