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

[Ryosuke Niwa]

On Tue, Mar 3, 2020 at 12:31 AM Noam Rosenthal <noam at webkit.org> wrote:

>
> On Tue, Mar 3, 2020 at 10:18 AM Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> Sorry for the delay. I had other other things to take care of first.
>>
>> Based on the discussion we had (between Maciej, Simon, Alan, and I), we
>> should take the following items into account for WebKit's first meaningful
>> paint heuristics:
>>
>>    - Background image
>>
>> I've filed https://bugs.webkit.org/show_bug.cgi?id=208501 and can get it
> done.
> Btw if there's something I'm taking on myself but Apple would rather do or
> vice versa, please let me know :)
>

Great. I've cc'ed a few more folks.

>
>>    - SVG images
>>    - "Contentful" canvas once we rigorously defined what it means:
>>    https://github.com/w3c/paint-timing/issues/50
>>    - First frame / poster image of a video:
>>    https://github.com/w3c/paint-timing/issues/51
>>
>> Then as Maciej pointed out there are a few spec works to do:
>>
>>    - WebKit takes any text regardless of whether they appear within UA
>>    shadow root or not into account for the first meaningful paint. The spec
>>    needs to clarify this behavior -
>>    https://github.com/w3c/paint-timing/issues/52
>>    - The exact timing of navigation should be defined -
>>    https://github.com/w3c/paint-timing/issues/19
>>    - Clarify whether "first paint" or "first content paint" ever happens
>>    to a blank page - https://github.com/w3c/paint-timing/issues/53
>>    - Clarify what happens to a page which consists of just an iframe -
>>    https://github.com/w3c/paint-timing/issues/54
>>    - Combination of paint timing and long tasks can expose precise paint
>>    timing - https://github.com/w3c/paint-timing/issues/55
>>
>> To supplement earlier Maciej's points, per our discussion, we don't think
>> "first paint" is a good metric to expose to the Web since Safari / WebKit
>> users would never see that. If any website optimize for the first paint
>> metrics instead of or at the cost of first contentful paint, then such an
>> optimization would only result in perceived regressions for our users.
>>
> I've spoken with the Wikipedia folks on this and they agree, first-paint
> is not really that useful as a performance metric (I think it's useful to
> catch bugs, e.g. in cases where it's vastly behind first-contentful-paint).
> For now I'm focusing only on the first-contentful-paint metric, and adding
> web platform tests to cover this situation (the current tests would fail in
> the case where FP is not implemented).
>

Sounds great to me.

By the way, do you know what the status / interests at Mozilla? Given
WebKit's painting / navigation behavior / implementation is still pretty
close to Blink, it would be a good idea to reach out to Mozilla to make
sure whatever in the spec is something they can also implement.

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