RE: [PerformanceTimeline] Returning Navigation Timing attributes in High Resolution Time

Karen and I discussed this in more detail last week. We felt that the confusion of including redundant APIs will exceed the benefit of adding the PerformanceTiming attributes in high resolution time in a PerformanceEntry. Most developers may wonder why a PerformanceTiming interface even exists or what the differences are between the two. Instead if we wanted to add high resolution support for Navigation Timing attributes, we should just update the Navigation Timing spec, and I am not a proponent of doing that as there are compatibility issues. Further, I don't think the use case of comparing a Navigation Timing attribute with a Resource Timing attribute will be common; the more common scenario of comparing the startTimes and durations, we already support.

I recommend we keep the spec as is. We already have done a good job of including Navigation Timing within the timeline in the Performance Timeline spec. If developers are interested in the individual timing attributes, they can look at performance.timing - it will be available in millisecond resolution.

Let's cover this in today's call.

Thanks,
Jatinder

From: Jatinder Mann [mailto:jmann@microsoft.com]
Sent: Wednesday, April 4, 2012 9:42 AM
To: public-web-perf@w3.org
Subject: [PerformanceTimeline] Returning Navigation Timing attributes in High Resolution Time

In order for Navigation Timing to take its respective place in the timeline, Section 4.4 of Performance Timeline defines a PerformanceEntry object for Navigation Timing that contains the "name", "entryType", "startTime" and "duration" attributes. With "startTime" and "duration", when looking at the entire timeline, the page navigation time is included along with resource and developer script data.

We previously had not considered adding the Navigation Timing attributes to the PerformanceEntry for Navigation Timing, as these attributes already exist in PerformanceTiming, as defined in the Navigation Timing spec.

However, whereas Resource Timing and User Timing benefit from having sub-millisecond timing information due to High Resolution Time (DOMHighResTimeStamp), individual Navigation Timing attributes are only given in millisecond resolution on the PerformanceTiming interface. Further, the attributes are in a different timebase, so it's difficult to compare the fetchStart of the navigation with the fetchStart of a particular resource, as an example.

For compatibility reasons, we do not want to change PerformanceTiming. However, should we consider adding the Navigation Timing attributes to the navigation PerformanceEntry? Each attribute would return a DOMHighResTimeStamp with the attribute definition linked to the Navigation Timing spec definition.

E.g., when invoking getEntries("navigation"), you would get the following object:

interface PerformanceNavigationTiming : PerformanceEntry {
  //Defined in PerformanceEntry
  // readonly DOMString name;
  // readonly DOMString entryType;
  // readonly DOMHighResTimeStamp startTime;
  // readonly DOMHighResTimeStamp duration;


  readonly attribute DOMHighResTimeStamp  navigationStart;
  readonly attribute DOMHighResTimeStamp  unloadEventStart;
  readonly attribute DOMHighResTimeStamp  unloadEventEnd;
  readonly attribute DOMHighResTimeStamp  redirectStart;
  readonly attribute DOMHighResTimeStamp  redirectEnd;
  readonly attribute DOMHighResTimeStamp  fetchStart;
  readonly attribute DOMHighResTimeStamp  domainLookupStart;
  readonly attribute DOMHighResTimeStamp  domainLookupEnd;
  readonly attribute DOMHighResTimeStamp  connectStart;
  readonly attribute DOMHighResTimeStamp  connectEnd;
  readonly attribute DOMHighResTimeStamp  secureConnectionStart;
  readonly attribute DOMHighResTimeStamp  requestStart;
  readonly attribute DOMHighResTimeStamp  responseStart;
  readonly attribute DOMHighResTimeStamp  responseEnd;
  readonly attribute DOMHighResTimeStamp  domLoading;
  readonly attribute DOMHighResTimeStamp  domInteractive;
  readonly attribute DOMHighResTimeStamp  domContentLoadedEventStart;
  readonly attribute DOMHighResTimeStamp  domContentLoadedEventEnd;
  readonly attribute DOMHighResTimeStamp  domComplete;
  readonly attribute DOMHighResTimeStamp  loadEventStart;
  readonly attribute DOMHighResTimeStamp loadEventEnd;
};

Let's discuss in the call today.

Thanks,
Jatinder