Description

I’d like to propose a focus area for Interop 2023 focused on Web Performance: Paint Timing. This work would include:

• Expanding and clarifying existing spec text for marking time points related to rendering, in Paint Timing and Element Timing APIs (already in progress). This will help with interop in the face of fundamental differences in rendering pipelines and how animation frames are measured and reported across implementers.
• Clarifying which specific animation frames should report paint timings, especially when multiple paints are involved during an iterative rendering process, e.g. paints and sync/async image decode, paints during render throttling such as page visibility changes, etc.
• Creating new WPT tests which do a better job of accurately testing if reported timings represent the actual visual progress of loading / responsiveness as observed, e.g. first contentful paint

Rationale

First Contentful Paint (FCP) is one of the more important moments in Loading User Experience and is used by many Real User Monitoring (RUM) services to measure and improve the quality of UX.

Firefox, Safari, Chromium, and Edge all implement First Contentful Paint, and so it offers unique value to web developers using the Performance Timeline. However, the exact time values exposed have some significant differences, and these have been a persistent source of developer frustration, discussion within the Web Performance WG, and with a history of unresolved spec issues:

• Timestamps should be specified in an interoperative way w3c/paint-timing#62
• requestAnimationFrame callback and LCP renderTime should be the same w3c/largest-contentful-paint#104
• Expose LCP renderTime in non-TAO cross-origin images, when it doesn't reflect the image decoding time w3c/largest-contentful-paint#91

We believe this stems from two underspecified/undertested issues:

1. Which timings are exposed for any measured animation frame (there are multiple useful time points)
2. Which specific animation frames are measured

The goal of this Interop 2023 proposal is to focus on First Contentful Paint, and a focus on loading measurement issues specific to image decode modes and page visibility state. The improvements are expected to be foundational, and will apply to interop to Largest Contentful Paint, Element Timing, and Event Timing -- but implementing those measures on all platforms is not considered for this proposal.

Specification

• The HTML Standard: “Update the rendering” steps of the event loop
• Updating w3c Paint Timing specification
• Moving some parts of existing wicg Element Timing specification into HTML or paint timing.

Will limit the focus primarily on the details required for the first-contentful-paint entry.

(Some changes may also be made to related Largest Contentful Paint and Event Timing specifications, but only insofar as they are already defined in-terms-of Paint & Element Timing, and where this interop work will offer clarification and simplification in those areas).

Tests

Testing paint timings relies on accurate matching of visual loading experience, as observed by a user, with reported metrics.
Thus, Automated testing seems possible only for some types of tests (i.e., basic functionality, testing which animation frame is reported on, etc) but we may need to rely on Manual/Visual tests to ensure timing values are accurate and representative (in some sense, this is like testing the quality/timing of an animation).

• paint-timing directory
• fcp-only tests
• Will write new tests for FCP specific to image decode (sync, async, decode()) (Example test page used in the past)
• Will write new manual/visual tests to verify what is actually visually observed

Work may affect tests in other features using paint timings:

• Element Timing
• LCP
• Event Timing