W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2011

NavigationTiming update with PerformanceEntry

From: Nic Jansma <Nic.Jansma@microsoft.com>
Date: Tue, 12 Jul 2011 18:02:42 +0000
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <F677C405AAD11B45963EEAE5202813BD35723C23@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Hi folks,

With the recent updates to the NavigationTiming spec (http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html), one of the changes is that NavigationTiming now participates in the Performance Timeline (http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#sec-performance-timeline).

To do this, NavigationTiming must somehow be exposed as a PerformanceEntry, which has these attributes:

interface PerformanceEntry {
  readonly attribute DOMString name;
  readonly attribute unsigned long long startTime;
  readonly attribute unsigned short entryType;
  readonly attribute unsigned long long duration;
};

As of today, there are two attributes that hang off of window.performance related to NavigationTiming:

*         window.performance.navigation - Metadata for the navigation, such as type redirectCount

*         window.performance.timing - Timestamps of phases of the navigation

My question for the group is: Should we have window.performance.timing inherit from PerformanceEntry, and thus also have the name, startTime, entryType and duration attributes?

The reason to do this would be to have consistency for the Performance Timeline, where all objects inherit form PerformanceEntry.

However, the downsides of doing this would be:

1.       The performance.timing object changes from all timestamps to a mixture of timestamps, durations, strings and enums (shorts).

2.       Consumers of the interface wouldn't be able to blindly sort all of the timestamps under performance.timing and place them on a timeline, as they're now a mixture of types.

3.       The processing model (http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#processing-model) for NavigationTiming would have to be updated and might be more confusing (for example, section 16.f refers referrs to zeroing out all performance.timing attributes)

4.       The Vendor Prefixes section (http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#vendor-prefixes) talks about the naming standard for attributes added to performance.timing.  The PerformanceEntry attributes don't follow this standard.

One way to work around this could be instead of updating performance.timing to inherit from PerformanceEntry, we leave it as-is.  Instead, if the user requests getEntry() and gets back a PERF_NAVIGATION object, then-and-only-then do we return a PerformanceTiming object that inherits from PerformanceEntry.

Another possibility is to have performance.navigation be the object that inherits from PerformanceEntry.

Thoughts?

- Nic
Received on Tuesday, 12 July 2011 18:03:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC