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

[Ryosuke Niwa]

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

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