[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)
From: Noam Rosenthal <noam () webkit ! org>
Date: 2020-03-03 8:31:11
Message-ID: CAGttnEVUOCqfqbAYhVwG+H7Vx8VAYTdJDgLph9Dsc-_GQ60N2g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Mar 3, 2020 at 10:18 AM Ryosuke Niwa <rniwa@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 :)
>
> - 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).
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Tue, Mar 3, 2020 at 10:18 AM Ryosuke Niwa <<a \
href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Sorry for the \
delay. I had other other things to take care of first.<div><br></div><div>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:</div><div><ul><li>Background \
image</li></ul></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div>I've \
filed <a href="https://bugs.webkit.org/show_bug.cgi?id=208501">https://bugs.webkit.org/show_bug.cgi?id=208501</a> \
and can get it done.<br>Btw if there's something I'm taking on myself but \
Apple would rather do or vice versa, please let me know :)</div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div><ul><li>SVG images</li><li>"Contentful" canvas once we \
rigorously defined what it means: <a \
href="https://github.com/w3c/paint-timing/issues/50" \
target="_blank">https://github.com/w3c/paint-timing/issues/50</a></li><li>First frame \
/ poster image of a video: <a href="https://github.com/w3c/paint-timing/issues/51" \
target="_blank">https://github.com/w3c/paint-timing/issues/51</a></li></ul><div>Then \
as Maciej pointed out there are a few spec works to do:</div><ul><li>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 - <a \
href="https://github.com/w3c/paint-timing/issues/52" \
target="_blank">https://github.com/w3c/paint-timing/issues/52</a></li><li>The exact \
timing of navigation should be defined - <a \
href="https://github.com/w3c/paint-timing/issues/19" \
target="_blank">https://github.com/w3c/paint-timing/issues/19</a><br></li><li>Clarify \
whether "first paint" or "first content paint" ever happens to a \
blank page - <a href="https://github.com/w3c/paint-timing/issues/53" \
target="_blank">https://github.com/w3c/paint-timing/issues/53</a><br></li><li>Clarify \
what happens to a page which consists of just an iframe - <a \
href="https://github.com/w3c/paint-timing/issues/54" \
target="_blank">https://github.com/w3c/paint-timing/issues/54</a><br></li><li>Combination \
of paint timing and long tasks can expose precise paint timing - <a \
href="https://github.com/w3c/paint-timing/issues/55" \
target="_blank">https://github.com/w3c/paint-timing/issues/55</a></li></ul><div>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.</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div>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).</div></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic