Intent to Implement First Paint Timing

[Jian Sun]

Contact emails

panicker@chromium.org, sunjian@chromium.org, tdre...@chromium.org

Summary

Explainer: https://github.com/tdresser/paint-timing

Discussed the API with W3C Web-Perf group at TPAC. There is strong interest in the API.

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.

For detailed motivation for First Paint, see the Why First Paint doc.

Interoperability and Compatibility Risk

Low.
Notifications will be exposed via well-defined Performance Observer interface and require explicit opt-in from application; notifications themselves have standard performance-entry format.

This will implemented behind a flag.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Requesting approval to ship?

No.

[Shubhie Panicker]

+relevant folks

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Elliott Sprehn]

As voiced in the meeting it's not clear to me that this is much more valuable than just calling requestAnimationFrame at the start of your app, the time when that first raf runs is the first available paint. The only thing this API seems to expose is the cost of the paint itself (which you could get with double-raf), except that since the first paint depends heavily on when the parser yeilds you don't really know what painted inside the first paint, it could be all white, or it could contain some content.

I think something closer to:

- First raf

- Hero timing

both seem better than FP itself.

[Shubhie Panicker]

To clarify, there are 2 timestamps being proposed here: First Paint (FP) & First Contentful Paint (FCP). Your concern is about FP, IIUC.

FP serves 2 major purposes:

1. FP targets non-default background paint, so it won't fire on white background paint. 

This is key difference between FP and first rAF. This is important for rewarding developers for quickly painting the brand color or app-shell for the site, even though they might not have painted any "content" (text, image etc) yet.

(benefit of using a service worker to render app-shell / background should be captured with this metric)

Tying it to a visual reference, helps connect this with the user experience: quickly communicating that "it is happening".

Now this could be the timestamp for the rAF after the non-default background paint. That is a separate discussion on whether the timestamp should be compositor commit time OR next rAF vs. paint time. This question applies to FCP (and future paint metrics) as well. (we have a discussion going with public-web-perf folks on that as I mentioned in the meeting)

2. FP also doubles as a "loading metric" for developers regarding their payload size.

This could also be captured as something more generic like first rAF (or 2nd rAF).

I don't think hero timing is the right substitute here as it requires developers to annotate markup, FP is a basic metric that should be available for all sites by default.

The questions are:

a. is #1 a worthwhile cause

b. should #2 be represented with a different metric like first rAF ?

My stance is that #1 is worthwhile, and the fact that is addresses #2 is great because we don't need a separate "loading metric".

[Alexander Semashko]

As far as I understand, the intent is to add to performance timeline the same timing that is currently exposed via chrome.loadTimes().firstPaintTime? If so, it seems a bit strange to me; is there a confidence that it will be standardized exactly this way, and is there a reason to implement it now? It looks like the users of these metrics may just end up having two non-standard ways of getting the first paint metric; correct me if I'm wrong, please.

6 дек. 2016 г., в 1:25, 'Shubhie Panicker' via blink-dev <blin...@chromium.org> написал(а):

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

—

Best regards,

Alexander Semashko

ah...@yandex-team.ru

[Shubhie Panicker]

As implemented chrome.loadTimes().firstPaintTime is same as FP metric, i.e. when we updated FP metric in the past year it also caused chrome.loadTimes().firstPaintTime to be updated (there is no divergence).
Although I'm not sure if that answers your question, can you clarify the question?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Alexander Semashko]

It answers the first part of the question, thanks :) The other part probably comes from my misunderstanding of the intent. If the intent is just to provide an example implementation for the future spec which is not yet meant to be tried by web developers, then everything is ok.

6 дек. 2016 г., в 1:53, Shubhie Panicker <pani...@google.com> написал(а):

—

С уважением,

Александр Семашко

ah...@yandex-team.ru

[Shubhie Panicker]

Ultimately we do want to deprecate chrome.loadTimes(), the standardized FP metric will be the replacement for it.

 

[Shubhie Panicker]

Let's continue this discussion on the WICG thread: https://discourse.wicg.io/t/expose-first-paint-timing-in-performance-observer/1868