Page MenuHomePhabricator

Consider aligning Chrome firstPaint with navStart (or fetchStart)
Closed, DeclinedPublic

Description

Per https://github.com/addyosmani/timing.js/issues/29, https://github.com/addyosmani/timing.js/commit/38a17bf60f1072d8431c3aa40b46d9351fd60e3f. It looks like we're currently computing Chrome's firstPaint based on chromeTimes.firstPaintTime - chromeTimes.startLoadTime. Which seems inconsistent with the other metrics.

This is especially important once we standardise on fetchStart.

Event Timeline

Krinkle created this task.Nov 2 2017, 9:12 PM
Restricted Application added a project: Performance-Team. · View Herald TranscriptNov 2 2017, 9:12 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Peter added a subscriber: Gilles.Nov 13 2017, 7:29 AM

I think we can do this when we move to the new first paint as @Gilles implemented for Asia (we should make that one default and then have the old loadTimes as a backup (loadTimes is getting deprecated so we should also make sure that we don't break on it)).

Imarlier triaged this task as Medium priority.Jan 18 2018, 2:35 PM
Krinkle closed this task as Declined.Feb 21 2018, 10:05 PM

Closing this in favour of T187334 and T104902.

We currently collect the IE/Edge and Chrome versions of firstPaint relative to navigation start. As part of the navtiming2 metrics (which are all relative to fetchStart), we should update firstPaint as well, but we can already do that on the server side by deducting fetchStart from the collected metric. In fact, I suspect we already do this.

That leaves:

  • Use Paint Timing API (recently standardised and implemented in Chrome only at the moment) instead of the older non-standard Chrome/IE implementations where possible. – Tracked as 187334.
  • Once navtiming2 is ready and adopted as our main source of metrics, consider computing relative to fetchStart directly on the client, which is part of T104902.