Bug 78011 – Implement Paint Timing Level 1

• Component: WebCore Misc.
• Status: RESOLVED CONFIGURATION CHANGED

[James Simonsen]

In order for Navigation Timing to fully supplant the client side instrumentation (CSI) that's custom added to browsers, we need to expose a first paint time to window.performance.timing. Microsoft already has this in IE10 as msFirstPaint. We should add webkitFirstPaint and work on standardizing the exact definition of first paint.

A spec has since emerged from WICG, and was published two years ago as W3C Working Draft (September 2017).

* Working Draft: https://www.w3.org/TR/paint-timing/
* Editor's Draft: https://w3c.github.io/paint-timing/
* https://github.com/w3c/paint-timing
* https://github.com/WICG/paint-timing

firstPaint, Paint Timing, PerformancePaintTiming.

[Noam Rosenthal]

Created attachment 392102 [details]
Patch for discussion (not for review yet)

[Noam Rosenthal]

The patch is not ready - the added skipped tests in TestExpectations tell where this doesn't fit the spec yet.

To detail of the approach:

There are 3 relevant milestones in WebKit painting:
- (A) The actual milestone used to decide when to unblock painting, called in webkit "DidFirstMeaningfulPaint".
patch). 
- (B) First paint, as defined in the spec. In this first patch, it's the same as the first milestone.
- (C) First contentful paint, called in webkit "DidFirstContentfulPaint" (new in this 

"DidFirstMeaningfulPaint" is not the same as first-paint - it's less strict in the sense that it would fire in case of no content at all or insufficient content, if the page is fully loaded and no content is expected at that phase. So DidFirstMeaningfulPaint can be fired even before first-paint and first-contentful-paint should fire according to spec. In 3 of the failing w3c tests, this is the case.

Also, first-contentful-paint, unlike DidFirstMeaningfulPaint, should fire when background images are rendered, and respond to rendered canvas only if it has any content.

We should decide whether to have first-contentful-paint adhere tightly to the spec (I believe so), or be closer to WebKit's concept of DidFirstMeaningfulPaint (less work, maybe). 

btw - it's true that in most websites A, B and C would happen at the same time - however, having a gap between them would be a good indication, in some cases, for

[Noam Rosenthal]

> btw - it's true that in most websites A, B and C would happen at the same
> time - however, having a gap between them would be a good indication, in
> some cases, for...
a website regression, which is part of what this API is for

[Radar WebKit Bug Importer]

<rdar://problem/59964760>

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

Oops, re-posting my comment because that was jumbled up.

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

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

We don't want to implement "first paint" metric because Safari / WebKit users would not see anything at when this timing occurs. If any website optimize for the first paint metrics instead of or at the cost of first contentful paint, such an optimization would only negatively impact our users.

[Noam Rosenthal]

(In reply to Ryosuke Niwa from comment #7)

To touch base on the discussion regarding paint API:
> we
> should take the following items into account for WebKit's first meaningful
> paint heuristics:
>  * SVG images
Landed, https://trac.webkit.org/changeset/257952/webkit

>  * Background image
Patch ready for review, https://bugs.webkit.org/show_bug.cgi?id=208501.

>  * "Contentful" canvas once we rigorously defined what it means:
> https://github.com/w3c/paint-timing/issues/50
Spec issue resolved, patch for canvas bassed on it: https://bugs.webkit.org/show_bug.cgi?id=208482


>  * First frame / poster image of a video:
> https://github.com/w3c/paint-timing/issues/51
Spec issue resolved, still need patch for VNE - want to resolve above 2 patches first as they contain similar functionality and would probably share code.

> 
> 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
Above spec issues resolved.

> 
> We don't want to implement "first paint" metric because Safari / WebKit
> users would not see anything at when this timing occurs. If any website
> optimize for the first paint metrics instead of or at the cost of first
> contentful paint, such an optimization would only negatively impact our
> users.
The spec now specifies that first-paint is optional. https://bugs.webkit.org/show_bug.cgi?id=208499 implements only first-contentful-paint.

Simon has raised the point about tests for VNE in https://bugs.webkit.org/show_bug.cgi?id=208482#c8 - do we want to land FCP and use it to test VNE, add a new way to test VNE, or leave it as is (contributing to VNE without tests)?

[Simon Fraser (smfr)]

Noam, the two blocking bugs are fixed. What remains here?

[Noam Rosenthal]

(In reply to Simon Fraser (smfr) from comment #9)
> Noam, the two blocking bugs are fixed. What remains here?

I think, just maturing paint-timing out of "experimental flag" land. What would be required for this?

[Simon Fraser (smfr)]

How confident are we in the implementation? How well does it match other browsers, and how well-tested is it by WPT?

[Noam Rosenthal]

(In reply to Simon Fraser (smfr) from comment #11)
> How confident are we in the implementation? How well does it match other
> browsers, and how well-tested is it by WPT?

It totally matches chrome after the few spec iteration we've done and has over 25 WPT tests that cover it, which were imported as part of the patch.

[Noam Rosenthal]

(In reply to Simon Fraser (smfr) from comment #11)
> How confident are we in the implementation? How well does it match other
> browsers, and how well-tested is it by WPT?

Re. the implementation - it's pretty straightforward, does a fake paint and reports the timing if contentfulness is detected.

I think the open issue is that it still doesn't support layout formatting context. I think we should do that once LFC implementation itself is a bit less in flux, but I don't know if this should be a blocker, not sure what the plan is regarding LFC.

[Simon Fraser (smfr)]

LFC is not a blocker. I think it would be fine to change the PaintTimingEnabled experimental feature to on by default. Perhaps mail webkit-dev to tell people that you're doing so.

[Simon Fraser (smfr)]

*** Bug 236155 has been marked as a duplicate of this bug. ***

[Ahmad Saleem]

Hi Team - is this something can be turned on by default in Safari now? Considering the comments in Comment 13 and Comment 14 and also in WPT (for Stable), I can see Safari 15.5 do pass some tests (not all).

https://wpt.fyi/results/paint-timing?label=master&label=stable&aligned

Although - there is "experimental" flag still present in Safari 15.5 on macOS 12.4 for "Paint Timing"? Is it because of "WPT" failures - it is still experimental? Thanks!

[Noam Rosenthal]

(In reply to Ahmad Saleem from comment #16)
> Hi Team - is this something can be turned on by default in Safari now?
> Considering the comments in Comment 13 and Comment 14 and also in WPT (for
> Stable), I can see Safari 15.5 do pass some tests (not all).
> 
> https://wpt.fyi/results/paint-timing?label=master&label=stable&aligned
> 
> Although - there is "experimental" flag still present in Safari 15.5 on
> macOS 12.4 for "Paint Timing"? Is it because of "WPT" failures - it is still
> experimental? Thanks!

It’s been enabled by default for a while now (first contentful paint only).
Some WPTs fail because WebKit chose to implement a subset.