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

Re: NavigationTiming update with PerformanceEntry

From: Zhiheng Wang <zhihengw@google.com>
Date: Wed, 13 Jul 2011 01:14:00 -0700
Message-ID: <CAA1TnvUDgZoUY3ZcdnkDOP4eq8YKwiFTzw841c41-x4d4aifVQ@mail.gmail.com>
To: Nic Jansma <Nic.Jansma@microsoft.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
On Tue, Jul 12, 2011 at 11:02 AM, Nic Jansma <Nic.Jansma@microsoft.com>wrote:

>  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.
>

   I for one don't think it's necessary to follow the inheritence here, for
all the reasons you mention. Besides, the extra interfaces create redundancy
for the spec itself.


> 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.
>
>
>

     This can be specified in ResourceTiming or UserTiming instead, when we
bring up the getEntry() interface?

cheers,
Zhiheng


>
>
> ** **
>
> Another possibility is to have performance.navigation be the object that
> inherits from PerformanceEntry.****
>
> ** **
>
> Thoughts?****
>
> ** **
>
> - Nic****
>
Received on Wednesday, 13 July 2011 08:14:26 UTC

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