Bug 78011

Summary: Implement Paint Timing Level 1
Product: WebKit Reporter: James Simonsen <simonjam>
Component: WebCore Misc.Assignee: James Simonsen <simonjam>
Status: NEW ---    
Severity: Normal CC: ahmad.saleem792, andrewscheuermann, ap, benjamin, calvaris, cdumez, emilio, esprehn+autocc, ews-watchlist, gilles, japhet, kondapallykalyan, krinklemail, mmaxfield, noam, paulirish, rego, rniwa, simon.fraser, tonyg, webkit-bug-importer, webkitbugzilla, youennf
Priority: P2 Keywords: InRadar, WebExposed, WPTImpact
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 208499, 208500, 211736    
Bug Blocks:    
Attachments:
Description Flags
Patch for discussion (not for review yet) none

Description James Simonsen 2012-02-07 11:43:38 PST
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.
Comment 1 krinklemail 2019-09-17 08:21:24 PDT
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.
Comment 2 Noam Rosenthal 2020-03-01 13:47:57 PST
Created attachment 392102 [details]
Patch for discussion (not for review yet)
Comment 3 Noam Rosenthal 2020-03-01 14:00:16 PST
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
Comment 4 Noam Rosenthal 2020-03-01 14:00:59 PST
> 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
Comment 5 Radar WebKit Bug Importer 2020-03-02 13:20:00 PST
<rdar://problem/59964760>
Comment 6 Ryosuke Niwa 2020-03-03 00:18:40 PST
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.
Comment 7 Ryosuke Niwa 2020-03-03 00:20:38 PST
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.
Comment 8 Noam Rosenthal 2020-04-01 12:39:08 PDT
(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)?
Comment 9 Simon Fraser (smfr) 2020-05-10 20:16:04 PDT
Noam, the two blocking bugs are fixed. What remains here?
Comment 10 Noam Rosenthal 2020-05-10 22:22:47 PDT
(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?
Comment 11 Simon Fraser (smfr) 2020-05-11 10:31:56 PDT
How confident are we in the implementation? How well does it match other browsers, and how well-tested is it by WPT?
Comment 12 Noam Rosenthal 2020-05-11 10:34:14 PDT
(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.
Comment 13 Noam Rosenthal 2020-05-11 10:45:20 PDT
(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.
Comment 14 Simon Fraser (smfr) 2020-05-11 11:31:21 PDT
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.
Comment 15 Simon Fraser (smfr) 2022-02-07 11:58:01 PST
*** Bug 236155 has been marked as a duplicate of this bug. ***
Comment 16 Ahmad Saleem 2022-06-15 14:57:52 PDT
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!
Comment 17 Noam Rosenthal 2022-06-16 00:03:09 PDT
(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.