Expose First Paint, First Contentful Paint, ... to developers

[igrigorik]

(discussed at TPAC 2016; rough notes and summary of discussed ideas below)

• Progressive Web Metrics
• Why First Paint as Web Perf API?

---

• We should expose these as a separate interface from NavigationTiming; NT entry is queued when the page has finished loading (after loadeventend), and based on our telemetry a significant portion of pages does not (e.g. due to user cancelling the navigation, etc). Since our goal here is to provide insight into the significant moments of the page load.. we should not block those on requirement that the page finishes loading.
• We probably want to define a single interface ~PerformancePaintTiming and vary the name based on the milestone + provide startTime of when it occurs.
• First Paint: define with respect to paint of the initial (CSS) containing block?
  • Avoid defining in terms of background color / "white paint" / etc.
• First Contentful Paint: first paint of something different from the box model?

note: combined with ~Element Timing API (see https://github.com/w3c/charter-webperf/issues/30) this could also enable "first meaningful paint".

[igrigorik]

• https://github.com/tdresser/time-to-first-paint
• https://github.com/tdresser/time-to-first-contentful-paint
• https://github.com/tdresser/time-to-first-meaningful-paint
• https://github.com/tdresser/time-to-interactive

@tdresser @spanicker @paulirish thinking out loud.. could we merge some of the above into a single proposal and move related discussion/work to WICG? That would help get input from other vendors, etc. At a minimum, I'm wondering if we can merge First + First Contentful paint into a single proposal? The other two are probably still a bit too early..

[tdresser]

Sorry for the delay here - any suggestion on the name of the combined proposal? I'll combine the TTFP and TTFCP explainers in a personal repo, and then move it to WICG?

[igrigorik]

Sorry for the delay here - any suggestion on the name of the combined proposal?

Paint Timing API, or some such? E.g..

PerformancePaintTiming : PerformanceEntry {
    entryType: "paint", 
    name: {"first-paint", "first-contentful-paint", ...}
    startTime: <DOMHighResTimeStamp>,
    duration: 0
};

I'll combine the TTFP and TTFCP explainers in a personal repo, and then move it to WICG?

sgtm!

[tdresser]

Shubhie commented that load-timing might be more appropriate if we plan to integrate TTI at some point. Does that sound reasonable?

[tdresser]

Combined explainer here, though I haven't switched the repo name. Shubhie, you may want to take another editing pass.

What's the process for moving this to WICG?

[igrigorik]

/cc @yoavweiss for the WICG assist :-)

@tdresser small nitpick: when we move the repo, can we rename it and drop the "first" / give it a more generic name to minimize confusion?

[igrigorik]

@tdresser reading through the merged explainer...

"first-paint" entries contain a DOMHighResTimeStamp reporting the time when the browser first painted anything non-white after a navigation. This is the first key moment developers care about in page load – when the browser has started to render the page.

When we discussed [1] this at TPAC, there was pushback on the "non-white" language: it's imprecise, doesn't account for theme colors (e.g. Chrome incognito background color is not white), etc. The suggestion was to define it with respect to the first paint of the initial containing block.

"first-contentful-paint" contain a DOMHighResTimestamp reporting the time when the browser first painted any text, image (including background images), non-white canvas or SVG. This includes text with pending webfonts. This is the first time users could start consuming page content.

Similar to above.. The proposal at TPAC was to define this as "first paint of something different from the box model".

[1] https://www.w3.org/2016/09/23-webperf-irc

[tdresser]

We'll absolutely want to rename - I figured it was probably easier to rename when moving that to rename separately.

Thanks - I've updated the first paint definition.

I'm not certain how to formalize "first paint of something different from the box model". The idea is to blacklist things that don't count as FCP, instead of whitelist things that do, correct? Any suggestions here?

[spanicker]

BTW I recall "initial containing block" as a suggestion from Ryosuke, though don't recall agreement. We also discussed the notion of "not-the-background color" vs. mentioning specific color. (just providing some context - if "initial containing block" works - that's awesome!)

[igrigorik]

I'm not certain how to formalize "first paint of something different from the box model". The idea is to blacklist things that don't count as FCP, instead of whitelist things that do, correct?

The high-level concern was that we don't want to enumerate all the plausible FCP cases -- e.g. image vs background image in CSS vs canvas vs ... and that's just for an image. So, roughly, the idea was that anytime we paint something other than the initial containing block.. call that FCP.

That said, I'm no CSS/layout/paint expert.. @rniwa @tabatkins @esprehn any thoughts or suggestions for how to define this one?

[rniwa]

I think such a metric would be necessarily implementation specific because each browser has its own rendering model. The best I can think of is to tie it to whatever Houdini's paint worklet uses. I think the closet thing I can find is the concept of draw a paint image.

[spanicker]

Quick update here: we updated the explainer:

• mention "initial containing block" and inclusion of non-default background paint
• the definition of FCP remains the same
• we are working on updating the HTML spec to indicate "paint" in the processing model step 7.12 (based on feedback from Houdini paint worklet folks)
• re the name: we are sticking with "PerformancePaintTiming"

PTAL.

[igrigorik]

In case anyone is looking: https://github.com/tdresser/time-to-first-paint/blob/master/README.md

Above LGTM.

@toddreifsteck @bzbarsky @smaug---- @rniwa any thoughts or input on this one? We're working on an implementation of these in Chrome, hoping to have something available to developers soon..

[toddreifsteck]

My biggest concern is the diff between these metrics and actual render time. I may be misunderstanding, but I think https://docs.google.com/spreadsheets/d/1nGauGA3EvN8NBC3ErWjLd8Bz-NzmmEa6q6UP5KhfgeA/edit#gid=1743549886 may illustrate my concern.

I believe we should add "render time" to the metric to allow both the UI thread impact and any other delays to be observed.

[addyosmani]

Shubhie commented that load-timing might be more appropriate if we plan to integrate TTI at some point. Does that sound reasonable?

I think Tim's proposed PerformancePaintTiming combination makes a lot of sense for FP, FCP and leaves room for a future FMP. At this time, will TTI be deferred to future work?

[igrigorik]

I believe we should add "render time" to the metric to allow both the UI thread impact and any other delays to be observed.

@toddreifsteck I'm not sure I follow.. What's your definition of "render time"?

@addyosmani re, TTI: yes, that one is still in prototyping stage. Also, based on discussion at TPAC, it sounded like we may be able to define on top of first paint / first meaningful paint and long tasks API, so those are our P0's right now.

[toddreifsteck]

@igrigorik There is a layout snap point defined in HTML5. After that, background threads may take time to process that layout before it is pushed to the GPU. I've observed that this delay is observable by users and certain complex web pages have significantly slower times than others. I assert that we need to make the delay between the UI thread and any background threads visible on this metric. I believe this was accounted for in FrameTiming back in the day as a second metric, but I generally believe it should be two numbers on the same metric given this definition. Do you follow what I'm getting at?

[spanicker]

Todd, is it fair to say that your concern is whether the reported timestamps correlate well with user perceived paint timing? If so, we could address this with comparing the reported timestamp with corresponding moments in WPT videos, with updated metric definitions.

[krutzler]

Definitely we want these metrics to accurately approximate what a test client like WPT (or a real user) "sees". But beware WPT, need a heavily tuned setup (ala FB Browser Lab) to get consistent results. I view this effort as one of the direct responses to the difficulty in getting reliable results from tools like WPT.

[toddreifsteck]

@spanicker I'm saying that marking a background thread/process time closer to the GPU will correlate more closely. I'm also saying that I've encountered developers optimizing UI thread and getting it wrong when background threads end up increasing their portion of the time. Because of this, I assert that we should add a "near GPU" time to increase the likelihood of correlation being correct. This timing was referred to as PerformanceCompositeTiming in https://rawgit.com/WICG/frame-timing/1b220bf8eeeafc3e51c5ed7e9725f72ea34f453c/index.html#performancerendertiming

[ctolkien]

Blink has announced intent to ship this feature: https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/7BZrqCfZ-OQ/R1H6vikdBQAJ

[igrigorik]

This is a thing now! Closing.

Please direct any further related discussions or comments to:

• https://w3c.github.io/paint-timing/
• https://github.com/w3c/paint-timing/issues/