> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal <noam.j.rosent...@gmail.com 
>> <mailto:noam.j.rosent...@gmail.com>> wrote:
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <m...@apple.com 
>> <mailto:m...@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 
>> <https://www.w3.org/TR/paint-timing/#sec-terminology>> does not match the 
>> definition stated at <https://web.dev/first-contentful-paint/ 
>> <https://web.dev/first-contentful-paint/>>. The Chrome definition on web.dev 
>> <http://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 
>> <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 
>> <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.
> First paint that’s not first meaningful/contentful paint is not a very good 
> performance metric IMO. Who cares that a paint happened if it doesn’t have 
> any image or text content?
> I also don’t think this exposes less. The privacy risk here is exposing 
> timing data that might be usable for fingerprinting.
>> 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.
> What’s the difference between First Meaningful and First Contentful?
> There is no difference in Safari because we don't do any painting of a newly 
> navigated until the first meaningful paint happens.

WebKit’s notion of First Meaningful Paint is not the same as Chrome’s, from the 
sound of it. It sounds closer to Chrome’s First Contentful Paint, which makes 
no attempt to exclude sidebars or navigation bars or the like. (But it does 
exclude iframe).

> - R. Niwa
>> 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?
> We will discuss with Apple’s privacy experts what they think of the privacy 
> risk. I’m just giving you a rain check for results of this discussion.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
webkit-dev mailing list

Reply via email to