WebKit position on Paint Timing / (first paint, first contentful paint)

# Noam Rosenthal (8 days ago)

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: bugs.webkit.org/show_bug.cgi?id=78011 Spec: www.w3.org/TR/paint-timing

Thanks! Noam

Contact us to advertise here
# Maciej Stachowiak (8 days ago)

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: www.w3.org/TR/paint-timing/#sec-terminology does not match the definition stated at 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.

# Noam Rosenthal (8 days ago)

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

# Maciej Stachowiak (7 days ago)

On Feb 26, 2020, at 10:51 AM, Noam Rosenthal <noam.j.rosenthal at gmail.com> wrote:

On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <mjs at apple.com <mailto:mjs at 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 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: w3c.github.io/paint-timing/#sec-reporting-paint-timing, 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: bugzilla.mozilla.org/show_bug.cgi?id=1518999, 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.

# Noam Rosenthal (7 days ago)

On Wed, Feb 26, 2020 at 9:29 PM Maciej Stachowiak <mjs at apple.com> 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 :)

# Ryosuke Niwa (7 days ago)

On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak <mjs at apple.com> wrote:

On Feb 26, 2020, at 10:51 AM, Noam Rosenthal <noam.j.rosenthal at gmail.com> wrote:

On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <mjs at 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 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: 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: 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
# Ryosuke Niwa (7 days ago)

On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal <noam at webkit.org> wrote:

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

On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:

On Feb 26, 2020, at 10:51 AM, Noam Rosenthal <noam.j.rosenthal at gmail.com <mailto:noam.j.rosenthal at gmail.com>> wrote:

On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <mjs at apple.com <mailto:mjs at 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 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: w3c.github.io/paint-timing/#sec-reporting-paint-timing, 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: bugzilla.mozilla.org/show_bug.cgi?id=1518999, 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).

# Ryosuke Niwa (7 days ago)

On Wed, Feb 26, 2020 at 9:00 PM Maciej Stachowiak <mjs at apple.com> wrote:

On Feb 26, 2020, at 2:25 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Wed, Feb 26, 2020 at 11:29 AM Maciej Stachowiak <mjs at apple.com> wrote:

> >

On Feb 26, 2020, at 10:51 AM, Noam Rosenthal <noam.j.rosenthal at gmail.com> wrote:

On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <mjs at 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 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: 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: 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
# Yoav Weiss (7 days ago)

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa at webkit.org> wrote:

On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal <noam at webkit.org> wrote:

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

# Noam Rosenthal (7 days ago)

On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <yoav at yoav.ws> wrote:

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa at webkit.org> 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.

# Yoav Weiss (7 days ago)

On Thu, Feb 27, 2020 at 11:47 AM Noam Rosenthal <noam at webkit.org> wrote:

On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <yoav at yoav.ws> wrote:

> >

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa at webkit.org> 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! :)

# Noam Rosenthal (7 days ago)

On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal <noam at webkit.org> wrote:

On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <yoav at yoav.ws> wrote:

> >

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa at webkit.org> 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?

# Maciej Stachowiak (7 days ago)

On Feb 27, 2020, at 3:41 AM, Noam Rosenthal <noam at webkit.org> wrote:

On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal <noam at webkit.org <mailto:noam at webkit.org>> wrote:

On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <yoav at yoav.ws <mailto:yoav at yoav.ws>> wrote:

On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa at webkit.org <mailto:rniwa at webkit.org>> 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.

# Noam Rosenthal (3 days ago)

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?

# Maciej Stachowiak (3 days ago)

On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <noam at webkit.org> 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.

# Noam Rosenthal (3 days ago)

On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak <mjs at apple.com> wrote:

On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <noam at webkit.org> 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).

# Maciej Stachowiak (3 days ago)

On Mar 1, 2020, at 2:57 PM, Noam Rosenthal <noam at webkit.org> wrote:

On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:

On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <noam at webkit.org <mailto:noam at webkit.org>> 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 want to change the spec to have this heuristic, or change that heuristic in webkit, or neither?

We want to change one or both of them to match, if at all possible.

# Noam Rosenthal (3 days ago)

On Mon, Mar 2, 2020 at 1:18 AM Maciej Stachowiak <mjs at apple.com> wrote:

On Mar 1, 2020, at 2:57 PM, Noam Rosenthal <noam at webkit.org> wrote:

On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak <mjs at apple.com> wrote:

> >

On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <noam at webkit.org> 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 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?

We want to change one or both of them to match, if at all possible.

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?

# Maciej Stachowiak (3 days ago)

On Mar 1, 2020, at 4:19 PM, Noam Rosenthal <noam at webkit.org> wrote:

On Mon, Mar 2, 2020 at 1:18 AM Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:

On Mar 1, 2020, at 2:57 PM, Noam Rosenthal <noam at webkit.org <mailto:noam at webkit.org>> wrote:

On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:

On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <noam at webkit.org <mailto:noam at webkit.org>> 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 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?

We want to change one or both of them to match, if at all possible. 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.

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.

# Noam Rosenthal (3 days ago)

On Mon, Mar 2, 2020 at 2:37 AM Maciej Stachowiak <mjs at apple.com> wrote:

On Mar 1, 2020, at 4:19 PM, Noam Rosenthal <noam at webkit.org> 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.

# Ryosuke Niwa (2 days ago)

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:

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 - w3c/paint-timing#52
  • The exact timing of navigation should be defined - w3c/paint-timing#19
  • Clarify whether "first paint" or "first content paint" ever happens to a blank page - w3c/paint-timing#53
  • Clarify what happens to a page which consists of just an iframe - w3c/paint-timing#54
  • Combination of paint timing and long tasks can expose precise paint timing - w3c/paint-timing#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
# Noam Rosenthal (2 days ago)

On Tue, Mar 3, 2020 at 10:18 AM Ryosuke Niwa <rniwa at webkit.org> 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 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 :)

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 - w3c/paint-timing#52
  • The exact timing of navigation should be defined - w3c/paint-timing#19
  • Clarify whether "first paint" or "first content paint" ever happens to a blank page - w3c/paint-timing#53
  • Clarify what happens to a page which consists of just an iframe - w3c/paint-timing#54
  • Combination of paint timing and long tasks can expose precise paint timing - w3c/paint-timing#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).

# Ryosuke Niwa (2 days ago)

On Tue, Mar 3, 2020 at 12:31 AM Noam Rosenthal <noam at webkit.org> wrote:

On Tue, Mar 3, 2020 at 10:18 AM Ryosuke Niwa <rniwa at webkit.org> 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 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.

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 - w3c/paint-timing#52
  • The exact timing of navigation should be defined - w3c/paint-timing#19
  • Clarify whether "first paint" or "first content paint" ever happens to a blank page - w3c/paint-timing#53
  • Clarify what happens to a page which consists of just an iframe - w3c/paint-timing#54
  • Combination of paint timing and long tasks can expose precise paint timing - w3c/paint-timing#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
# Noam Rosenthal (2 days ago)

On Tue, Mar 3, 2020 at 10:36 AM Ryosuke Niwa <rniwa at webkit.org> 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:

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

# Maciej Stachowiak (5 hours ago)

On Mar 3, 2020, at 12:44 AM, Noam Rosenthal <noam at webkit.org> wrote:

On Tue, Mar 3, 2020 at 10:36 AM Ryosuke Niwa <rniwa at webkit.org <mailto:rniwa at webkit.org>> 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: bugzilla.mozilla.org/show_bug.cgi?id=1518999, 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).

Want more features?

Request early access to our private beta of readable email premium.