[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-02-26 18:53:43
Message-ID: CAGttnEW8z_ORoa7SZL-rtnX9xyoiesjLFCZ3pgCWg6PQFYZuzQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
(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 think that for the main
use-case of catching regressions for website code, it's ok (and almost
unpreventable) if the implementations have some variances between them,
what matters is that the metric is reliable for the particular browser.
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.
>
> Chrome team themselves have been telling web developers that First
> Contentful Paint is deprecated in favor of Largest Contentful Paint. Should
> we concerned about this? It seems even harder to define LCP in an
> engine-independent way.
>
What was deprecated was "first meaningful paint" (FMP). FCP was not
deprecated and has been in wide use for some time.
>
> Finally, we should do a privacy review to consider whether exposing this
> info to webpages creates fingerprinting risk or otherwise exposes user data.
>
Great, what is needed for such review?
[Attachment #5 (text/html)]
<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="m_-1443612026114392812gmail-:3ur0" \
style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px"><div \
id="m_-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. I think that for \
the main use-case of catching regressions for website code, it's ok (and almost \
unpreventable) if the implementations have some variances between them, what matters \
is that the metric is reliable for the particular browser. <br>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><span \
style="color:rgb(80,0,80)"><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><div><br></div><div>Chrome team themselves \
have been telling web developers that First Contentful Paint is deprecated in favor \
of Largest Contentful Paint. Should we concerned about this? It seems even harder to \
define LCP in an engine-independent way.</div></div></blockquote></span><div>What was \
deprecated was "first meaningful paint" (FMP). FCP was not deprecated and \
has been in wide use for some time.<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><br></div><div>Finally, we should do a \
privacy review to consider whether exposing this info to webpages creates \
fingerprinting risk or otherwise exposes user \
data.</div></div></blockquote></span><div>Great, what is needed for such \
review?<div></div><div><br></div></div></div></div><div></div></div></div><div \
style="border-bottom-left-radius:1px;border-bottom-right-radius:1px;padding:0px;width: \
auto;background:rgb(242,242,242);margin:0px"></div></div></div><br></div></div></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