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

[Yoav Weiss]

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa at webkit.org> wrote:

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

With my WebPerfWG hat on, I agree. Would be good to find a model that works
well for different implementations (even if not comparable between
different implementations), while providing points in time for developers
that can: a) provide a user meaningful visual metric and b) enable spotting
regressions.

Would WebKit folks be interested in helping exploration on that front?


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

FWIW, I don't think it's a huge problem if WebKit will report FP and FCP as
the same timestamp, as they are indeed the same point in time.


> - R. Niwa
>
> _______________________________________________
> 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/20200227/e76d57c1/attachment.htm>