We recently landed a few changes to move us closer to being able to merge cross-frame paint timings in the browser process:

1. zhenw@ fixed a bug where paint timings in child frames where reported in the top frame: https://bugs.chromium.org/p/chromium/issues/detail?id=705315
2. I landed a patch that merges paint timings for all frames in a page when reporting first paints to observers: https://codereview.chromium.org/2859393002

With this change we continue to report page-level first paints however the implementation is somewhat different: instead of merging timings in the render process (due to the bug zhen fixed) we now merge timings reported from different frames in the browser process.

This should be a no-op but there is some risk for timings to arrive out of order - for example we might see:

1. main frame starts parsing
2. main frame sends initial timing update
3. main frame paints
4. main frame schedules a timer to send updated timing to browser process
5. child frame created
6. child frame paints
7. child frame sends initial timing update
8. main frame dispatches timing update

In this case, the browser will most likely receive the paint message for the child frame first, even though the main frame painted first. I expected this to be rare, but metrics suggest that this happens more than I had hoped - it affects about 4% of pages, adding on average 370ms for affected pages, increasing mean TTFP by 15ms across all page loads (on canary, anyway).

So I think we need to fix this, given that it adds a significant delay to mean paint timings.

Observers only want their First*PaintInPage callbacks to be invoked once per page. So if we know that we sometimes receive per-frame first paints out of order, unless we want to complicate observers to understand that this can happen, we probably want to buffer timing updates in the browser process, at the PageLoadTracker level, for a period before dispatching to observers, so we are able to wait to dispatch the real/correct first paint times to observers.

We already have some logic in the browser to buffer timing updates that we know are received out of order before dispatching them to observers. If for example we receive a first paint in a child frame before we'e received first parse in the main frame, we buffer the paint update until we've received the parse update, since observers reasonably assume we can't paint without having started parsing.

I believe what we need to do here is also buffer paint timing updates for a period of time before dispatching to observers, in case we receive subsequent updates for a paint that happened earlier in the page. The UMA suggests that a delay of 1s is reasonable - this makes sense since this is our buffering timer delay in the render process. So I will plan to buffer paint updates for 1s: when we receive our first first paint of a given type (e.g. FP, FCP, FMP, etc) across all frames in the page, we will set a timer for 1s, and dispatch the most recently received PageLoadTiming during that 1s to observers once the timer fires. This allows us to receive out of order updates that arrive up to 1s late, and still report the right page level information to observers. I'll add UMA to see how much this corrects the issue & we can tune the timeout accordingly.