Expose First Paint* Timing in Performance Observer

We’d like to expose timing for First Paint & First Contentful Paint in the Performance Observer. ###Motivation No single moment in time completely captures the user’s “loading experience”. To give developers insight into the loading experience, we propose a set of key progress metrics to capture the series of key moments during pageload which developers care about. First Paint (FP), is the first of these key moments, followed by First Contentful Paint (FCP). In the future, we plan to expose more such key moments, to help developers understand the full loading experience.

Link to Proposal: https://github.com/tdresser/paint-timing Relevant github discussion: https://github.com/w3c/charter-webperf/issues/32

Considering the wide support this proposal seen at the WebPerfWG F2F at TPAC, the repo was moved under the WICG org: https://github.com/WICG/paint-timing

Couple issues have been raised on the Blink Intent thread and the public-web-perf meeting, that I’d like to discuss here.

The concerns are:

1. FP is not very actionable by developers, it can move due to browser changes. Also developers wouldn’t know what exactly painted at reported FP (except that it’s something more than blank screen).
2. Instead of FP why not expose first rAF as a proxy metric for “browser is starting to render”.
3. If exposing paint times, ensure it captures the full cost of the paint, specifically include time in compositor, or round to next rAF.

I am amenable to #3 and wiling to consider #2 if there’s support here, however I wanted to address #1 i.e. why exposing FP is a good thing: FP is the first visual signal to end users that “it is happening” therefore it’s a good thing for developers to know. However developers should not fixate on FP alone, rather it adds value when considered together with FCP (and proposed Hero Element Timing API). In that sense it’s an important diagnostic metric. For instance addition of 200ms between FP and FCP is a negative signal that developers should dig into.

Feedback is welcome!

/cc @toddreifsteck @igrigorik

Re (1): I believe “Why first paint” already answers this… Yes, in isolation it’s not sufficient to understand the full picture, but when combined with other metrics it helps developers understand how their pages are being painted. If the browsers change their heuristics, that’s good to know, as I might want to update how I construct + ship my page.

Re (2): as in, record the time of first rAF and call that first paint? Correct me if I’m wrong, but this wouldn’t account for the cases when all you’ve painted is default background color? The intent behind FP is to refine that and make sure that at leas something other than default background is on the screen.

Re (3): It’d be helpful to break down what edge-cases these proposals would actually solve. As in, if we round everything to next rAF, what are we accounting for that we didn’t before, what did we regress, etc. I don’t have a clear picture of what these cases are, so it’s hard to make a call one way or another.