Bug 78011 - Implement Paint Timing Level 1
Summary: Implement Paint Timing Level 1
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: James Simonsen
URL:
Keywords: InRadar, WebExposed, WPTImpact
Depends on: 211736 208499 208500
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-07 11:43 PST by James Simonsen
Modified: 2020-05-27 14:09 PDT (History)
19 users (show)

See Also:


Attachments
Patch for discussion (not for review yet) (96.89 KB, patch)
2020-03-01 13:47 PST, Noam Rosenthal
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.