[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: Maciej Stachowiak <mjs () apple ! com>
Date: 2020-02-26 18:08:15
Message-ID: C678A92B-EFC4-4864-8389-BBA4C4F63B6C () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Some quick comments:
I am concerned that the definitions of these paint milestones have engine-dependent \
assumptions, and some may not be spelled out in the spec.
For example, 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?
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?
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.
Finally, we should do a privacy review to consider whether exposing this info to \
webpages creates fingerprinting risk or otherwise exposes user data.
Regards,
Maciej
> On Feb 26, 2020, at 3:32 AM, Noam Rosenthal <noam@webkit.org> wrote:
>
> Hola
> I was approached by the Wikimedia foundation to implement the paint timing API for \
> WebKit (yay). I think this is a good feature to have for webkit, and I wanted to \
> hear thoughts about it before I begin.
> The feature was enabled in Chrome for quite a while, and is potentially very useful \
> for real user monitoring to see if changes to the code of the website create \
> performance regressions on different browsers. We've been using it extensively (on \
> Chrome) when I worked at Wix.com, and always hoped that "some day" it will be \
> available in other browsers.
> I think it's a pretty lean spec and was stable since 2017, and that it fits with \
> the WebKit project goals, by allowing web developers to better optimize their \
> content and catch Safari/WebKit-specific regressions early.
> I would like to get feedback on whether it's a desired feature for WebKit, if there \
> are caveats/pitfalls I should be thinking about, and anything else that's worth \
> mentioning at this point.
> There are of course delicate decisions to be made as to the choice of timing \
> indicator, but I will get to that once we've sorted out the position in general.
> Bug: https://bugs.webkit.org/show_bug.cgi?id=78011 \
> <https://bugs.webkit.org/show_bug.cgi?id=78011>
> Spec: https://www.w3.org/TR/paint-timing/ <https://www.w3.org/TR/paint-timing/>
>
> Thanks!
> Noam
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><div class=""><br class=""></div><div \
class="">Some quick comments:</div><div class=""><br class=""></div><div class="">I \
am concerned that the definitions of these paint milestones have engine-dependent \
assumptions, and some may not be spelled out in the spec.</div><div class=""><br \
class=""></div><div class="">For example, the definition of First Contentful Paint \
here in the spec: <<a href="https://www.w3.org/TR/paint-timing/#sec-terminology" \
class="">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/" \
class="">https://web.dev/first-contentful-paint/</a>>. 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?</div><div \
class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br \
class=""></div><div class="">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 class=""><br class=""></div><div \
class="">Regards,</div><div class="">Maciej</div><div><br class=""><blockquote \
type="cite" class=""><div class="">On Feb 26, 2020, at 3:32 AM, Noam Rosenthal <<a \
href="mailto:noam@webkit.org" class="">noam@webkit.org</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hola<br \
class="">I was approached by the Wikimedia foundation to implement the paint timing \
API for WebKit (yay).<br class="">I think this is a good feature to have for webkit, \
and I wanted to hear thoughts about it before I begin.<br class=""><br class="">The \
feature was enabled in Chrome for quite a while, and is potentially very useful \
for real user monitoring to see if changes to the code of the website create \
performance regressions on different browsers.<div class="">We've been using it \
extensively (on Chrome) when I worked at <a href="http://Wix.com" \
class="">Wix.com</a>, and always hoped that "some day" it will be available in other \
browsers.<br class=""><br class="">I think it's a pretty lean spec and was stable \
since 2017, and that it fits with the WebKit project goals, by allowing web \
developers to better optimize their content and catch Safari/WebKit-specific \
regressions early.<br class=""><br class="">I would like to get feedback on whether \
it's a desired feature for WebKit, if there are caveats/pitfalls I should be thinking \
about, and anything else that's worth mentioning at this point.<br class=""><br \
class="">There are of course delicate decisions to be made as to the choice of timing \
indicator, but I will get to that once we've sorted out the position in general.<br \
class=""><br class="">Bug: <a \
href="https://bugs.webkit.org/show_bug.cgi?id=78011" \
class="">https://bugs.webkit.org/show_bug.cgi?id=78011</a><br class="">Spec: <a \
href="https://www.w3.org/TR/paint-timing/" \
class="">https://www.w3.org/TR/paint-timing/</a><br class=""><br class="">Thanks!<br \
class="">Noam</div></div> _______________________________________________<br \
class="">webkit-dev mailing list<br class=""><a \
href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br \
class=""></div></blockquote></div><br class=""></body></html>
_______________________________________________
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