[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: Yoav Weiss <yoav () yoav ! ws>
Date: 2020-02-27 10:17:19
Message-ID: CACj=BEiVUBVQ6ZQECjn3Op77u2B=8K70Prpw0kgA70PQMEZt1A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
>
> 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.
>
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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Wed, Feb 26, 2020 at 11:33 PM 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"><br></div><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 26, 2020 at 10:54 \
AM Noam Rosenthal <<a href="mailto:noam@webkit.org" \
target="_blank">noam@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 \
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_-1737756844861071197gmail-m_-519912390563961536m_-1443612026114392812gmail-:3ur0" \
style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px"><div \
id="gmail-m_-1737756844861071197gmail-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 <<a href="mailto:mjs@apple.com" \
target="_blank">mjs@apple.com</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><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:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>the definition of First \
Contentful Paint here in the spec: <<a \
href="https://www.w3.org/TR/paint-timing/#sec-terminology" \
target="_blank">https://www.w3.org/TR/paint-timing/#sec-terminology</a>> does not \
match the definition stated at <<a href="https://web.dev/first-contentful-paint/" \
target="_blank">https://web.dev/first-contentful-paint/</a>>. 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'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:1px solid \
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'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 "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. \
</div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>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.</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></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Would \
WebKit folks be interested in helping exploration on that front?</div><div> \
</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 \
class="gmail_quote"><div><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 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_-1737756844861071197gmail-m_-519912390563961536m_-1443612026114392812gmail-:3ur0" \
style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px"><div \
id="gmail-m_-1737756844861071197gmail-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 \
"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. \
</div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I \
don't think we don't should that because we don't have an equivalent of \
first-paint.</div></div></div></blockquote><div><br></div><div>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.</div><div><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 \
class="gmail_quote"><div><br></div><div>- R. Niwa</div><div><br></div></div></div> \
_______________________________________________<br> webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" \
target="_blank">webkit-dev@lists.webkit.org</a><br> <a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" \
target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br> \
</blockquote></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