'[webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)
From:       Noam Rosenthal <noam () webkit ! org>
Date:       2020-02-26 11:32:05
Message-ID: CAGttnEVtw_O+-KHWi-hd6=sA_bdSoFARAD-xK5UES1Op-1wfkw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

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
Spec: https://www.w3.org/TR/paint-timing/

Thanks!
Noam

[Attachment #5 (text/html)]

<div dir="ltr">Hola<br>I was approached by the Wikimedia foundation to implement the \
paint timing API for WebKit (yay).<br>I think this is a good feature to have for \
webkit, and I wanted to hear thoughts about it before I begin.<br><br>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>We&#39;ve been using it extensively (on \
Chrome) when I worked at Wix.com, and always hoped that &quot;some day&quot; it will \
be available in other browsers.<br><br>I think it&#39;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><br>I would like to get feedback on whether it&#39;s a desired \
feature for WebKit, if there are caveats/pitfalls I should be thinking about, and \
anything else that&#39;s worth mentioning at this point.<br><br>There are of course \
delicate decisions to be made as to the choice of timing indicator, but I will get to \
that once we&#39;ve sorted out the position in general.<br><br>Bug:  <a \
href="https://bugs.webkit.org/show_bug.cgi?id=78011">https://bugs.webkit.org/show_bug.cgi?id=78011</a><br>Spec: \
<a href="https://www.w3.org/TR/paint-timing/">https://www.w3.org/TR/paint-timing/</a><br><br>Thanks!<br>Noam</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] 