[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:       Ryosuke Niwa <rniwa () webkit ! org>
Date:       2020-02-26 22:30:19
Message-ID: CABNRm63AHGG7ixdRSu3cmWQTsRgxqRngN2m7Br2J3mp7aHN4HQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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

> (resending from correct address)
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <mjs@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

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal &lt;<a \
href="mailto:noam@webkit.org">noam@webkit.org</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>(resending from \
correct address)  <br><div style="margin:0px;padding:0px 0px \
20px;width:839px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><div><div \
id="gmail-m_-519912390563961536m_-1443612026114392812gmail-:3ur0" \
style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px"><div \
id="gmail-m_-519912390563961536m_-1443612026114392812gmail-:3ure" \
style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font \
-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div \
dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 26, \
2020 at 8:08 PM Maciej Stachowiak &lt;<a href="mailto:mjs@apple.com" \
target="_blank">mjs@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>Some \
quick comments:  </div></div></blockquote><span \
style="color:rgb(80,0,80)"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>the \
definition of First Contentful Paint here in the spec: &lt;<a \
href="https://www.w3.org/TR/paint-timing/#sec-terminology" \
target="_blank">https://www.w3.org/TR/paint-timing/#sec-terminology</a>&gt; does not \
match the definition stated at &lt;<a href="https://web.dev/first-contentful-paint/" \
target="_blank">https://web.dev/first-contentful-paint/</a>&gt;. The Chrome \
definition on  <a href="http://web.dev/" target="_blank">web.dev</a>  specifies that \
iframe content is not included, the spec does not have this limitation. Would an \
implementation that matches the spec match \
Chrome?</div></div></blockquote></span><div>The draft version of the spec specifies \
that iframe content is not included in FCP:    <a \
href="https://w3c.github.io/paint-timing/#sec-reporting-paint-timing" \
target="_blank">https://w3c.github.io/paint-timing/#sec-reporting-paint-timing</a>, \
and has a few more comprehensive details about this. I think it&#39;s a good place to \
start.<br><br></div><span style="color:rgb(80,0,80)"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>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?</div></div></blockquote></span><div>No, this has not been implemented in \
Gecko, I&#39;m tracking the bug on this:  <a \
href="https://bugzilla.mozilla.org/show_bug.cgi?id=1518999" \
target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1518999</a>, there was \
some movement recently.<br><br>I suggest to start from &quot;first-paint&quot;, and \
to try to match chrome as much as possible in how FCP is implemented, in the cases \
where the spec doesn&#39;t give enough detail, if such places exist.  \
</div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I \
don&#39;t think we should do that. For starters, Chrome&#39;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&#39;t update the painting until the destination page has a meaningful content \
in it. This is a very much different from Chrome&#39;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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div \
style="margin:0px;padding:0px 0px \
20px;width:839px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><div><div \
id="gmail-m_-519912390563961536m_-1443612026114392812gmail-:3ur0" \
style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px"><div \
id="gmail-m_-519912390563961536m_-1443612026114392812gmail-:3ure" \
style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font \
-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div \
dir="ltr"><div class="gmail_quote"><div>I also suggest to start with \
&quot;first-paint&quot; as it&#39;s perhaps a bit less &quot;internal&quot; than FCP, \
and can provide a performance-regression metric with a lesser degree of risk \
regarding exposing internals / privacy.  \
</div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I \
don&#39;t think we don&#39;t should that because we don&#39;t have an equivalent of \
first-paint.</div><div><br></div><div>- R. Niwa</div><div><br></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