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

[Maciej Stachowiak]

> On Mar 3, 2020, at 12:44 AM, Noam Rosenthal  wrote:
> 
> 
> 
> On Tue, Mar 3, 2020 at 10:36 AM Ryosuke Niwa  > wrote:
> 
> By the way, do you know what the status / interests at Mozilla? Given 
> WebKit's painting / navigation behavior / implementation is still pretty 
> close to Blink, it would be a good idea to reach out to Mozilla to make sure 
> whatever in the spec is something they can also implement.
> 
> Mozilla have a bug open on this: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1518999 
> , but unfortunately it 
> is not prioritized.
> Since they're mainly a desktop browser web developers currently don't 
> prioritize them for a performance metric. I hope that changes.

This explains a lot about the performance of desktop websites…

(Though in fairness, many mobile sites are not so great either).

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

On Tue, Mar 3, 2020 at 10:36 AM Ryosuke Niwa  wrote:

>
> By the way, do you know what the status / interests at Mozilla? Given
> WebKit's painting / navigation behavior / implementation is still pretty
> close to Blink, it would be a good idea to reach out to Mozilla to make
> sure whatever in the spec is something they can also implement.
>
> Mozilla have a bug open on this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1518999, but unfortunately it
is not prioritized.
Since they're mainly a desktop browser web developers currently don't
prioritize them for a performance metric. I hope that changes.
~Noam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Tue, Mar 3, 2020 at 12:31 AM Noam Rosenthal  wrote:

>
> On Tue, Mar 3, 2020 at 10:18 AM Ryosuke Niwa  wrote:
>
>> Sorry for the delay. I had other other things to take care of first.
>>
>> Based on the discussion we had (between Maciej, Simon, Alan, and I), we
>> should take the following items into account for WebKit's first meaningful
>> paint heuristics:
>>
>>- Background image
>>
>> I've filed https://bugs.webkit.org/show_bug.cgi?id=208501 and can get it
> done.
> Btw if there's something I'm taking on myself but Apple would rather do or
> vice versa, please let me know :)
>

Great. I've cc'ed a few more folks.

>
>>- SVG images
>>- "Contentful" canvas once we rigorously defined what it means:
>>https://github.com/w3c/paint-timing/issues/50
>>- First frame / poster image of a video:
>>https://github.com/w3c/paint-timing/issues/51
>>
>> Then as Maciej pointed out there are a few spec works to do:
>>
>>- WebKit takes any text regardless of whether they appear within UA
>>shadow root or not into account for the first meaningful paint. The spec
>>needs to clarify this behavior -
>>https://github.com/w3c/paint-timing/issues/52
>>- The exact timing of navigation should be defined -
>>https://github.com/w3c/paint-timing/issues/19
>>- Clarify whether "first paint" or "first content paint" ever happens
>>to a blank page - https://github.com/w3c/paint-timing/issues/53
>>- Clarify what happens to a page which consists of just an iframe -
>>https://github.com/w3c/paint-timing/issues/54
>>- Combination of paint timing and long tasks can expose precise paint
>>timing - https://github.com/w3c/paint-timing/issues/55
>>
>> To supplement earlier Maciej's points, per our discussion, we don't think
>> "first paint" is a good metric to expose to the Web since Safari / WebKit
>> users would never see that. If any website optimize for the first paint
>> metrics instead of or at the cost of first contentful paint, then such an
>> optimization would only result in perceived regressions for our users.
>>
> I've spoken with the Wikipedia folks on this and they agree, first-paint
> is not really that useful as a performance metric (I think it's useful to
> catch bugs, e.g. in cases where it's vastly behind first-contentful-paint).
> For now I'm focusing only on the first-contentful-paint metric, and adding
> web platform tests to cover this situation (the current tests would fail in
> the case where FP is not implemented).
>

Sounds great to me.

By the way, do you know what the status / interests at Mozilla? Given
WebKit's painting / navigation behavior / implementation is still pretty
close to Blink, it would be a good idea to reach out to Mozilla to make
sure whatever in the spec is something they can also implement.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

On Tue, Mar 3, 2020 at 10:18 AM Ryosuke Niwa  wrote:

> Sorry for the delay. I had other other things to take care of first.
>
> Based on the discussion we had (between Maciej, Simon, Alan, and I), we
> should take the following items into account for WebKit's first meaningful
> paint heuristics:
>
>- Background image
>
> I've filed https://bugs.webkit.org/show_bug.cgi?id=208501 and can get it
done.
Btw if there's something I'm taking on myself but Apple would rather do or
vice versa, please let me know :)

>
>- SVG images
>- "Contentful" canvas once we rigorously defined what it means:
>https://github.com/w3c/paint-timing/issues/50
>- First frame / poster image of a video:
>https://github.com/w3c/paint-timing/issues/51
>
> Then as Maciej pointed out there are a few spec works to do:
>
>- WebKit takes any text regardless of whether they appear within UA
>shadow root or not into account for the first meaningful paint. The spec
>needs to clarify this behavior -
>https://github.com/w3c/paint-timing/issues/52
>- The exact timing of navigation should be defined -
>https://github.com/w3c/paint-timing/issues/19
>- Clarify whether "first paint" or "first content paint" ever happens
>to a blank page - https://github.com/w3c/paint-timing/issues/53
>- Clarify what happens to a page which consists of just an iframe -
>https://github.com/w3c/paint-timing/issues/54
>- Combination of paint timing and long tasks can expose precise paint
>timing - https://github.com/w3c/paint-timing/issues/55
>
> To supplement earlier Maciej's points, per our discussion, we don't think
> "first paint" is a good metric to expose to the Web since Safari / WebKit
> users would never see that. If any website optimize for the first paint
> metrics instead of or at the cost of first contentful paint, then such an
> optimization would only result in perceived regressions for our users.
>
I've spoken with the Wikipedia folks on this and they agree, first-paint is
not really that useful as a performance metric (I think it's useful to
catch bugs, e.g. in cases where it's vastly behind first-contentful-paint).
For now I'm focusing only on the first-contentful-paint metric, and adding
web platform tests to cover this situation (the current tests would fail in
the case where FP is not implemented).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

Sorry for the delay. I had other other things to take care of first.

Based on the discussion we had (between Maciej, Simon, Alan, and I), we
should take the following items into account for WebKit's first meaningful
paint heuristics:

   - Background image
   - SVG images
   - "Contentful" canvas once we rigorously defined what it means:
   https://github.com/w3c/paint-timing/issues/50
   - First frame / poster image of a video:
   https://github.com/w3c/paint-timing/issues/51

Then as Maciej pointed out there are a few spec works to do:

   - WebKit takes any text regardless of whether they appear within UA
   shadow root or not into account for the first meaningful paint. The spec
   needs to clarify this behavior -
   https://github.com/w3c/paint-timing/issues/52
   - The exact timing of navigation should be defined -
   https://github.com/w3c/paint-timing/issues/19
   - Clarify whether "first paint" or "first content paint" ever happens to
   a blank page - https://github.com/w3c/paint-timing/issues/53
   - Clarify what happens to a page which consists of just an iframe -
   https://github.com/w3c/paint-timing/issues/54
   - Combination of paint timing and long tasks can expose precise paint
   timing - https://github.com/w3c/paint-timing/issues/55

To supplement earlier Maciej's points, per our discussion, we don't think
"first paint" is a good metric to expose to the Web since Safari / WebKit
users would never see that. If any website optimize for the first paint
metrics instead of or at the cost of first contentful paint, then such an
optimization would only result in perceived regressions for our users.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

On Mon, Mar 2, 2020 at 2:37 AM Maciej Stachowiak  wrote:

>
>
> On Mar 1, 2020, at 4:19 PM, Noam Rosenthal  wrote:
> OK, to summarize what I got from this
> - we want the spec and webkit painting to be as close as possible
> - The spec needs to be clearer/less buggy about a few things, such as
> "White" canvas, spec issues to be files
> - WebKit should be closer to the spec wrt canvas, backgrounds and
> potentially pixel/character threshold (TBD)
> - FP is more sensitive than FCP, because it exposes browser differences
> and may lead to unwanted comparisons and misunderstanding. Thus, it should
> be exposed as a different runtime feature flag.
>
> One thing I'm wondering about - would it be better to change the rendering
> heuristics together with implementing the paint API reporting? Or would it
> be better to separate those concerns a bit in terms of implementation? I
> mean, having the performance APIs in the code behind 2 flags with failed
> tests conforming to the spec might help iterate on the actual rendering.
> What would you consider a better approach here?
>
>
> If I were doing this myself, I’d first change rendering heuristics
> (probably without a flag) and then add the web-facing API.
>
Okay, let's see how that goes.


> What you describe might be reasonable if there are WPT conformance tests
> that can distinguish cases where the FCP timing is too late or too soon.
> It’s probably possible to make such tests, but I am not sure if they
> already exist.
>
They exist to some extent, webkit currently fails 4 out of 13 painting-API
conformance tests, around some of the issues discussed here (e.g. one of
the tests fails because webkit doesn't consider background image to be
contentful). I think I'll work on a few more while working on the spec,
they're quite easy to write.

Cheers
Noam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

> On Mar 1, 2020, at 4:19 PM, Noam Rosenthal  wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 1:18 AM Maciej Stachowiak  > wrote:
> 
> 
>> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal > > wrote:
>> 
>> 
>> 
>> On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak > > wrote:
>> 
>> 
>>> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal >> > wrote:
>>> 
>>> 
>>> The first visually non-empty milestone almost always happens way before 
>>> this point. The above is just a fallback to make sure we eventually hit 
>>> this milestone. For example, if a document is totally blank even after 
>>> loading the document and all subresources, we want to paint it instead of 
>>> waiting forever.
>>> 
>>> The visually non-empty heuristic is elsewhere.
>>> 
>>> Note that WebKit would consider the paint triggered by the above fallback 
>>> code to be both a first paint and “first visually non-empty paint” or 
>>> “first meaningful paint”, which somewhat corresponds to Chrome’s notion of 
>>> “first contentful paint”.
>>> 
>>> First paint can only happen earlier under even more unusual circumstances, 
>>> I believe there is a timeout after which we will paint even if all we can 
>>> paint is blank white or background color.
>>> 
 
 But let's take the specifics to Slack/bugzilla?
>>> 
>>> I think it would be good for you to talk to people who understand WebKit’s 
>>> layout/paint milestones in detail before taking things to bugzilla. Ask on 
>>> Slack, and I’ll point you to the right people.
>>> Oops, just saw this, an initial (not for review) patch is already in 
>>> bugzilla :)
>>> But I'll continue the discussion - I have better idea of what to ask now.
>>> Who would be the right people to ask?
>> 
>> Alan, Simon, and Ryosuke should all know about this.
>> Awesomeness.
>>  
>> 
>> A few of us sat down and reviewed this spec. We think that, as written, the 
>> definition of “first contentful paint” is underspecified and in some cases 
>> buggy. For example, it says a “non-white canvas” should count as contentful. 
>> But canvases don’t start as white, they start as fully transparent black 
>> (all zeros). And checking the color of every pixel in a canvas is expensive. 
>> The intent here is probably that a canvas that has ever been painted into is 
>> contentful (or one that has been painted into more recently than the last 
>> time it was cleared).
>> Yes, I also thought that part of the spec was strange. I'll help revise it.
>> btw the FirstMeaningfulPaint in webkit doesn't look at canvas content at all 
>> - rather on the creation of a RenderCanvasElement... maybe being closer to 
>> the spec here would be better rendering-wise? Also, the current layout 
>> milestones doen't consider background images as "rendered pixels". Is that 
>> on purpose?
> 
> We think background images (and SVG, if not included yet) should count as 
> meaningful content. And canvases should probably be limited to non-empty ones.
> OK - that's more like the spec.
>  
> 
>>  
>> 
>> In any case, it definitely does not match the WebKit notion of first 
>> visually non-empty layout / first meaningful paint, in some cases in ways 
>> that we regret.
>> Regret, as in - it was better if the spec was closer to what webkit was 
>> doing?
> 
> No, I mean in some cases we think we should do what the spec says.
> 
>> I think it's OK if the spec's FCP and webkit's FMP are not the same, and if 
>> FCP is fired according to spec, and after the actual painting in webkit was 
>> done. 
> 
> I think we should try to align with the spec. Otherwise, because WebKit 
> usually won’t paint at all until webkit-FMP time, FCP won’t fire until that 
> time (since it is only fired when an actual paint happens).
>  
> 
>> 
>> Spec issues to follow.
>> 
>> We also think exposing “first paint” is harmful and we’d rather not 
>> implement it. We don’t agree that painting non-contentful content quickly is 
>> a good idea, either for browsers or for websites. And this API will 
>> inevitably be used to compare browsers, regardless of disclaimers that it 
>> shouldn’t be.
>> Harmful in the sense of comparing browsers? I don't think it can, regardless 
>> of disclaimers - since the hardware used for the browsers (at least on 
>> mobile) is vastly different, and also the networks. How about exposing a 
>> prefixed entry? e.g. "-webkit-first-paint" - something that doesn't try to 
>> seem comparable? The goal here is to help people optimize their site and 
>> make sure it doesn't regress on webkit, rather than create meaningless 
>> cross-browser comparisons... 
> 
> We will probably take up our complaint in the form of a spec issue. In the 
> meantime, it would be nice if first paint was controlled by a separate flag.
> 
>> 
>> In any case even having first-contentful-paint would be useful - with or 
>> without first-paint.
>> 
>> 
>> It’s probably unwise to implement this until the spec is fixed. 

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

[Noam Rosenthal]

On Mon, Mar 2, 2020 at 1:18 AM Maciej Stachowiak  wrote:

>
>
> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal  wrote:
>
>
>
> On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak  wrote:
>
>>
>>
>> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal  wrote:
>>
>>
>>> The first visually non-empty milestone almost always happens way before
>>> this point. The above is just a fallback to make sure we eventually hit
>>> this milestone. For example, if a document is totally blank even after
>>> loading the document and all subresources, we want to paint it instead of
>>> waiting forever.
>>>
>>> The visually non-empty heuristic is elsewhere.
>>>
>>> Note that WebKit would consider the paint triggered by the above
>>> fallback code to be both a first paint and “first visually non-empty paint”
>>> or “first meaningful paint”, which somewhat corresponds to Chrome’s notion
>>> of “first contentful paint”.
>>>
>>> First paint can only happen earlier under even more unusual
>>> circumstances, I believe there is a timeout after which we will paint even
>>> if all we can paint is blank white or background color.
>>>
>>>
>>> But let's take the specifics to Slack/bugzilla?
>>>
>>>
>>> I think it would be good for you to talk to people who understand
>>> WebKit’s layout/paint milestones in detail before taking things to
>>> bugzilla. Ask on Slack, and I’ll point you to the right people.
>>>
>> Oops, just saw this, an initial (not for review) patch is already in
>> bugzilla :)
>> But I'll continue the discussion - I have better idea of what to ask now.
>> Who would be the right people to ask?
>>
>>
>> Alan, Simon, and Ryosuke should all know about this.
>>
> Awesomeness.
>
>
>>
>> A few of us sat down and reviewed this spec. We think that, as written,
>> the definition of “first contentful paint” is underspecified and in some
>> cases buggy. For example, it says a “non-white canvas” should count as
>> contentful. But canvases don’t start as white, they start as fully
>> transparent black (all zeros). And checking the color of every pixel in a
>> canvas is expensive. The intent here is probably that a canvas that has
>> ever been painted into is contentful (or one that has been painted into
>> more recently than the last time it was cleared).
>>
> Yes, I also thought that part of the spec was strange. I'll help revise it.
> btw the FirstMeaningfulPaint in webkit doesn't look at canvas content at
> all - rather on the creation of a RenderCanvasElement... maybe being closer
> to the spec here would be better rendering-wise? Also, the current layout
> milestones doen't consider background images as "rendered pixels". Is that
> on purpose?
>
>
> We think background images (and SVG, if not included yet) should count as
> meaningful content. And canvases should probably be limited to non-empty
> ones.
>
OK - that's more like the spec.


>
>
>
>>
>> In any case, it definitely does not match the WebKit notion of first
>> visually non-empty layout / first meaningful paint, in some cases in ways
>> that we regret.
>>
> Regret, as in - it was better if the spec was closer to what webkit was
> doing?
>
>
> No, I mean in some cases we think we should do what the spec says.
>
> I think it's OK if the spec's FCP and webkit's FMP are not the same, and
> if FCP is fired according to spec, and after the actual painting in webkit
> was done.
>
>
> I think we should try to align with the spec. Otherwise, because WebKit
> usually won’t paint at all until webkit-FMP time, FCP won’t fire until that
> time (since it is only fired when an actual paint happens).
>


>
>
>> Spec issues to follow.
>>
>> We also think exposing “first paint” is harmful and we’d rather not
>> implement it. We don’t agree that painting non-contentful content quickly
>> is a good idea, either for browsers or for websites. And this API will
>> inevitably be used to compare browsers, regardless of disclaimers that it
>> shouldn’t be.
>>
> Harmful in the sense of comparing browsers? I don't think it can,
> regardless of disclaimers - since the hardware used for the browsers (at
> least on mobile) is vastly different, and also the networks. How about
> exposing a prefixed entry? e.g. "-webkit-first-paint" - something that
> doesn't try to seem comparable? The goal here is to help people optimize
> their site and make sure it doesn't regress on webkit, rather than create
> meaningless cross-browser comparisons...
>
>
> We will probably take up our complaint in the form of a spec issue. In the
> meantime, it would be nice if first paint was controlled by a separate flag.
>

>
> In any case even having first-contentful-paint would be useful - with or
> without first-paint.
>
>
>> It’s probably unwise to implement this until the spec is fixed. And once
>> it is, we should change our “first visually non-empty layout” notion to
>> match it before exposing the corresponding paint timing milestone.
>>
> Not sure that's necessary. We can match the spec without changing the way
> we render. For 

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

[Maciej Stachowiak]

> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal  wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak  > wrote:
> 
> 
>> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal > > wrote:
>> 
>> 
>> The first visually non-empty milestone almost always happens way before this 
>> point. The above is just a fallback to make sure we eventually hit this 
>> milestone. For example, if a document is totally blank even after loading 
>> the document and all subresources, we want to paint it instead of waiting 
>> forever.
>> 
>> The visually non-empty heuristic is elsewhere.
>> 
>> Note that WebKit would consider the paint triggered by the above fallback 
>> code to be both a first paint and “first visually non-empty paint” or “first 
>> meaningful paint”, which somewhat corresponds to Chrome’s notion of “first 
>> contentful paint”.
>> 
>> First paint can only happen earlier under even more unusual circumstances, I 
>> believe there is a timeout after which we will paint even if all we can 
>> paint is blank white or background color.
>> 
>>> 
>>> But let's take the specifics to Slack/bugzilla?
>> 
>> I think it would be good for you to talk to people who understand WebKit’s 
>> layout/paint milestones in detail before taking things to bugzilla. Ask on 
>> Slack, and I’ll point you to the right people.
>> Oops, just saw this, an initial (not for review) patch is already in 
>> bugzilla :)
>> But I'll continue the discussion - I have better idea of what to ask now.
>> Who would be the right people to ask?
> 
> Alan, Simon, and Ryosuke should all know about this.
> Awesomeness.
>  
> 
> A few of us sat down and reviewed this spec. We think that, as written, the 
> definition of “first contentful paint” is underspecified and in some cases 
> buggy. For example, it says a “non-white canvas” should count as contentful. 
> But canvases don’t start as white, they start as fully transparent black (all 
> zeros). And checking the color of every pixel in a canvas is expensive. The 
> intent here is probably that a canvas that has ever been painted into is 
> contentful (or one that has been painted into more recently than the last 
> time it was cleared).
> Yes, I also thought that part of the spec was strange. I'll help revise it.
> btw the FirstMeaningfulPaint in webkit doesn't look at canvas content at all 
> - rather on the creation of a RenderCanvasElement... maybe being closer to 
> the spec here would be better rendering-wise? Also, the current layout 
> milestones doen't consider background images as "rendered pixels". Is that on 
> purpose?

We think background images (and SVG, if not included yet) should count as 
meaningful content. And canvases should probably be limited to non-empty ones.

>  
> 
> In any case, it definitely does not match the WebKit notion of first visually 
> non-empty layout / first meaningful paint, in some cases in ways that we 
> regret.
> Regret, as in - it was better if the spec was closer to what webkit was doing?

No, I mean in some cases we think we should do what the spec says.

> I think it's OK if the spec's FCP and webkit's FMP are not the same, and if 
> FCP is fired according to spec, and after the actual painting in webkit was 
> done. 

I think we should try to align with the spec. Otherwise, because WebKit usually 
won’t paint at all until webkit-FMP time, FCP won’t fire until that time (since 
it is only fired when an actual paint happens).

> 
> Spec issues to follow.
> 
> We also think exposing “first paint” is harmful and we’d rather not implement 
> it. We don’t agree that painting non-contentful content quickly is a good 
> idea, either for browsers or for websites. And this API will inevitably be 
> used to compare browsers, regardless of disclaimers that it shouldn’t be.
> Harmful in the sense of comparing browsers? I don't think it can, regardless 
> of disclaimers - since the hardware used for the browsers (at least on 
> mobile) is vastly different, and also the networks. How about exposing a 
> prefixed entry? e.g. "-webkit-first-paint" - something that doesn't try to 
> seem comparable? The goal here is to help people optimize their site and make 
> sure it doesn't regress on webkit, rather than create meaningless 
> cross-browser comparisons... 

We will probably take up our complaint in the form of a spec issue. In the 
meantime, it would be nice if first paint was controlled by a separate flag.

> 
> In any case even having first-contentful-paint would be useful - with or 
> without first-paint.
> 
> 
> It’s probably unwise to implement this until the spec is fixed. And once it 
> is, we should change our “first visually non-empty layout” notion to match it 
> before exposing the corresponding paint timing milestone.
> Not sure that's necessary. We can match the spec without changing the way we 
> render. For example, “first visually non-empty layout" needs a minimum amount 
> of pixels/characters - do we 

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

[Noam Rosenthal]

On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak  wrote:

>
>
> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal  wrote:
>
>
>> The first visually non-empty milestone almost always happens way before
>> this point. The above is just a fallback to make sure we eventually hit
>> this milestone. For example, if a document is totally blank even after
>> loading the document and all subresources, we want to paint it instead of
>> waiting forever.
>>
>> The visually non-empty heuristic is elsewhere.
>>
>> Note that WebKit would consider the paint triggered by the above fallback
>> code to be both a first paint and “first visually non-empty paint” or
>> “first meaningful paint”, which somewhat corresponds to Chrome’s notion of
>> “first contentful paint”.
>>
>> First paint can only happen earlier under even more unusual
>> circumstances, I believe there is a timeout after which we will paint even
>> if all we can paint is blank white or background color.
>>
>>
>> But let's take the specifics to Slack/bugzilla?
>>
>>
>> I think it would be good for you to talk to people who understand
>> WebKit’s layout/paint milestones in detail before taking things to
>> bugzilla. Ask on Slack, and I’ll point you to the right people.
>>
> Oops, just saw this, an initial (not for review) patch is already in
> bugzilla :)
> But I'll continue the discussion - I have better idea of what to ask now.
> Who would be the right people to ask?
>
>
> Alan, Simon, and Ryosuke should all know about this.
>
Awesomeness.


>
> A few of us sat down and reviewed this spec. We think that, as written,
> the definition of “first contentful paint” is underspecified and in some
> cases buggy. For example, it says a “non-white canvas” should count as
> contentful. But canvases don’t start as white, they start as fully
> transparent black (all zeros). And checking the color of every pixel in a
> canvas is expensive. The intent here is probably that a canvas that has
> ever been painted into is contentful (or one that has been painted into
> more recently than the last time it was cleared).
>
Yes, I also thought that part of the spec was strange. I'll help revise it.
btw the FirstMeaningfulPaint in webkit doesn't look at canvas content at
all - rather on the creation of a RenderCanvasElement... maybe being closer
to the spec here would be better rendering-wise? Also, the current layout
milestones doen't consider background images as "rendered pixels". Is that
on purpose?


>
> In any case, it definitely does not match the WebKit notion of first
> visually non-empty layout / first meaningful paint, in some cases in ways
> that we regret.
>
Regret, as in - it was better if the spec was closer to what webkit was
doing?
I think it's OK if the spec's FCP and webkit's FMP are not the same, and if
FCP is fired according to spec, and after the actual painting in webkit was
done.

>
> Spec issues to follow.
>
> We also think exposing “first paint” is harmful and we’d rather not
> implement it. We don’t agree that painting non-contentful content quickly
> is a good idea, either for browsers or for websites. And this API will
> inevitably be used to compare browsers, regardless of disclaimers that it
> shouldn’t be.
>
Harmful in the sense of comparing browsers? I don't think it can,
regardless of disclaimers - since the hardware used for the browsers (at
least on mobile) is vastly different, and also the networks. How about
exposing a prefixed entry? e.g. "-webkit-first-paint" - something that
doesn't try to seem comparable? The goal here is to help people optimize
their site and make sure it doesn't regress on webkit, rather than create
meaningless cross-browser comparisons...

In any case even having first-contentful-paint would be useful - with or
without first-paint.


> It’s probably unwise to implement this until the spec is fixed. And once
> it is, we should change our “first visually non-empty layout” notion to
> match it before exposing the corresponding paint timing milestone.
>
Not sure that's necessary. We can match the spec without changing the way
we render. For example, “first visually non-empty layout" needs a minimum
amount of pixels/characters - do we want to change the spec to have this
heuristic, or change that heuristic in webkit, or neither? I'm actually
fine with any of these (speaking for what Wikipedia and other web-devs
would want), as long as we give web-devs some way to measure something that
they can count on to a degree :)


>
> I think Ryosuke took notes on the spec issues we need to file.
>
Ryusoke, will you share those notes with me? I can change the spec myself
(I'm on the web perf group now).

>
> Regards,
> Maciej
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal  wrote:
> 
> 
> The first visually non-empty milestone almost always happens way before this 
> point. The above is just a fallback to make sure we eventually hit this 
> milestone. For example, if a document is totally blank even after loading the 
> document and all subresources, we want to paint it instead of waiting forever.
> 
> The visually non-empty heuristic is elsewhere.
> 
> Note that WebKit would consider the paint triggered by the above fallback 
> code to be both a first paint and “first visually non-empty paint” or “first 
> meaningful paint”, which somewhat corresponds to Chrome’s notion of “first 
> contentful paint”.
> 
> First paint can only happen earlier under even more unusual circumstances, I 
> believe there is a timeout after which we will paint even if all we can paint 
> is blank white or background color.
> 
>> 
>> But let's take the specifics to Slack/bugzilla?
> 
> I think it would be good for you to talk to people who understand WebKit’s 
> layout/paint milestones in detail before taking things to bugzilla. Ask on 
> Slack, and I’ll point you to the right people.
> Oops, just saw this, an initial (not for review) patch is already in bugzilla 
> :)
> But I'll continue the discussion - I have better idea of what to ask now.
> Who would be the right people to ask?

Alan, Simon, and Ryosuke should all know about this.

A few of us sat down and reviewed this spec. We think that, as written, the 
definition of “first contentful paint” is underspecified and in some cases 
buggy. For example, it says a “non-white canvas” should count as contentful. 
But canvases don’t start as white, they start as fully transparent black (all 
zeros). And checking the color of every pixel in a canvas is expensive. The 
intent here is probably that a canvas that has ever been painted into is 
contentful (or one that has been painted into more recently than the last time 
it was cleared).

In any case, it definitely does not match the WebKit notion of first visually 
non-empty layout / first meaningful paint, in some cases in ways that we regret.

Spec issues to follow.

We also think exposing “first paint” is harmful and we’d rather not implement 
it. We don’t agree that painting non-contentful content quickly is a good idea, 
either for browsers or for websites. And this API will inevitably be used to 
compare browsers, regardless of disclaimers that it shouldn’t be.

It’s probably unwise to implement this until the spec is fixed. And once it is, 
we should change our “first visually non-empty layout” notion to match it 
before exposing the corresponding paint timing milestone.

I think Ryosuke took notes on the spec issues we need to file.

Regards,
Maciej___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

>
>
> The first visually non-empty milestone almost always happens way before
> this point. The above is just a fallback to make sure we eventually hit
> this milestone. For example, if a document is totally blank even after
> loading the document and all subresources, we want to paint it instead of
> waiting forever.
>
> The visually non-empty heuristic is elsewhere.
>
> Note that WebKit would consider the paint triggered by the above fallback
> code to be both a first paint and “first visually non-empty paint” or
> “first meaningful paint”, which somewhat corresponds to Chrome’s notion of
> “first contentful paint”.
>
> First paint can only happen earlier under even more unusual circumstances,
> I believe there is a timeout after which we will paint even if all we can
> paint is blank white or background color.
>
>
> But let's take the specifics to Slack/bugzilla?
>
>
> I think it would be good for you to talk to people who understand WebKit’s
> layout/paint milestones in detail before taking things to bugzilla. Ask on
> Slack, and I’ll point you to the right people.
>
Oops, just saw this, an initial (not for review) patch is already in
bugzilla :)
But I'll continue the discussion - I have better idea of what to ask now.
Who would be the right people to ask?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

> On Feb 27, 2020, at 3:41 AM, Noam Rosenthal  wrote:
> 
> 
> 
> On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal  > wrote:
> 
> 
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  > wrote:
> 
> 
> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  > wrote:
> 
> 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.
> Body background color is still painted before any contentful paint... Is this 
> a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with 
> bgcolors). Would webkit not render that web page at all? 
> 
> It seems like the code in FrameView does this:
> // Ensure that we always fire visually non-empty milestone eventually.
> if (finishedParsingMainDocument && frame().loader().isComplete())
> return true;
> 
> I suggest splitting this to two milestones - the current one, that triggers 
> when the main document finished loading, and another one that only triggers 
> when content has actually been painted (which may never happen). I think this 
> would be a good split for first-paint/first-contentful-paint in WebKit.

The first visually non-empty milestone almost always happens way before this 
point. The above is just a fallback to make sure we eventually hit this 
milestone. For example, if a document is totally blank even after loading the 
document and all subresources, we want to paint it instead of waiting forever.

The visually non-empty heuristic is elsewhere.

Note that WebKit would consider the paint triggered by the above fallback code 
to be both a first paint and “first visually non-empty paint” or “first 
meaningful paint”, which somewhat corresponds to Chrome’s notion of “first 
contentful paint”.

First paint can only happen earlier under even more unusual circumstances, I 
believe there is a timeout after which we will paint even if all we can paint 
is blank white or background color.

> 
> But let's take the specifics to Slack/bugzilla?

I think it would be good for you to talk to people who understand WebKit’s 
layout/paint milestones in detail before taking things to bugzilla. Ask on 
Slack, and I’ll point you to the right people.

> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal  wrote:

>
>
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:
>>
>>>
>>> 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.
>>>
>> Body background color is still painted before any contentful paint... Is
> this a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with
> bgcolors). Would webkit not render that web page at all?
>

It seems like the code in FrameView does this:

// Ensure that we always fire visually non-empty milestone eventually.

*if* (finishedParsingMainDocument && frame().loader().isComplete())

*return* *true*;

I suggest splitting this to two milestones - the current one, that triggers
when the main document finished loading, and another one that only triggers
when content has actually been painted (which may never happen). I think
this would be a good split for first-paint/first-contentful-paint in WebKit.

But let's take the specifics to Slack/bugzilla?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Yoav Weiss]

On Thu, Feb 27, 2020 at 11:47 AM Noam Rosenthal  wrote:

>
>
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:
>>
>>>
>>> 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.
>>>
>> Body background color is still painted before any contentful paint... Is
> this a bug?
> Also, a web page might not have content at all (e.g. a bunch of divs with
> bgcolors). Would webkit not render that web page at all?
>
>>
>>> 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.
>>
> Note taken. Though this is hypothetical - let's get to the point where the
> spec is lacking, and then we can decide how to go about it.
> What I propose is to go as far as possible with the spec, and when we
> reach an ambiguity tackle it on the spec front.
>
>>
>> Would WebKit folks be interested in helping exploration on that front?
>>
> I would be happy to help coordinate this (e.g. work on the details of pec
> differences and prod Ryosuke and folks for feedback about internals).
>

That sounds great, thank you! :)


>
>
>>
>>> 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.
>>
> A simple test shows that safari does show the background color
> (body=bgcolor) when a timeout is set to render everything else (e.g. add
> text to the document). According to the spec, the first one should give
> first-paint and the second one would be first-contentful-paint.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss  wrote:

>
>
> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:
>
>>
>> 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.
>>
> Body background color is still painted before any contentful paint... Is
this a bug?
Also, a web page might not have content at all (e.g. a bunch of divs with
bgcolors). Would webkit not render that web page at all?

>
>> 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.
>
Note taken. Though this is hypothetical - let's get to the point where the
spec is lacking, and then we can decide how to go about it.
What I propose is to go as far as possible with the spec, and when we reach
an ambiguity tackle it on the spec front.

>
> Would WebKit folks be interested in helping exploration on that front?
>
I would be happy to help coordinate this (e.g. work on the details of pec
differences and prod Ryosuke and folks for feedback about internals).


>
>> 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.
>
A simple test shows that safari does show the background color
(body=bgcolor) when a timeout is set to render everything else (e.g. add
text to the document). According to the spec, the first one should give
first-paint and the second one would be first-contentful-paint.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Yoav Weiss]

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa  wrote:

>
> On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal  wrote:
>
>> (resending from correct address)
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Wed, Feb 26, 2020 at 9:00 PM Maciej Stachowiak  wrote:

>
>
> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa  wrote:
>
>
> On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  wrote:
>
>>
>>
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal 
>> wrote:
>>
>>
>>
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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.
>>
>>
>> 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).
>

Well, WebKit does have heuristics like the number of characters that have
been laid out to gate the initial paint whereas Blink makes no such
attempts for having the first contentful paint (it just means the painted
content has something more than pure white / blank tile).

Note (for folks not familiar with WebKit's navigation / painting model)
that, by definition, WebKit's first painting of a newly navigated page *is*
the first contentful paint and also the first paint because we never even
attempt to paint the page until then (if we did paint the newly navigated
page prior to that point, that'd be considered as a bug).

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

> On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa  wrote:
> 
> 
> On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  > wrote:
> 
> 
>> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal > > wrote:
>> 
>> 
>> 
>> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak > > wrote:
>> 
>> Some quick comments: 
>> 
>> the definition of First Contentful Paint here in the spec: 
>> > > does not match the 
>> definition stated at > >. 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.
> 
> 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 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal  wrote:

> (resending from correct address)
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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.

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.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak  wrote:

>
>
> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal 
> wrote:
>
>
>
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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.
>
>
> 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.

- 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
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

On Wed, Feb 26, 2020 at 9:29 PM Maciej Stachowiak  wrote:

> 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 think it's meaningful as a general regression metric, albeit less useful
than FCP. Web developers are scrambling for any RUM information they can
use...


> I also don’t think this exposes less. The privacy risk here is exposing
> timing data that might be usable for fingerprinting.
>
Yes, I think that privacy-relevant timing information is already available
through resource timing (window.performance.getEntries("resource")). But
we'll see what the privacy experts come up with.


> 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?
>
FMP had the notion of "primary" content; e.g. it was ignoring
navbars/headers, and trying to figure out when the main content of the site
has been rendered.  As noted, FMP is deprecated. FCP is a lot more
transparent in what it measures.

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.
>
Got it, Looking forward :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

> On Feb 26, 2020, at 10:51 AM, Noam Rosenthal  
> wrote:
> 
> 
> 
> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  > wrote:
> 
> Some quick comments: 
> 
> the definition of First Contentful Paint here in the spec: 
>  > does not match the 
> definition stated at  >. 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.

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?

>  
> 
> 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
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

(resending from correct address)
On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak  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 . 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?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

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: 
 does not match the 
definition stated at . 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  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 
> 
> Spec: 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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Noam Rosenthal]

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev