W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2012

RE: [minutes] 2012-04-25 Web Performance WG Teleconference #70

From: Jatinder Mann <jmann@microsoft.com>
Date: Fri, 27 Apr 2012 17:59:22 +0000
To: Sigbjørn Vik <sigbjorn@opera.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <AE5FFD9402CD4F4785E812F2C9929D6504EA64AB@SN2PRD0310MB383.namprd03.prod.outlook.com>
> This leaves me with a few questions. What is/was section 4.4 of the Performance Timeline? 
> What are the additions that Jatinder suggested? What is the rationale behind this move? It seems 
> we have enough micro-specs already, we don't need any more, and I am not sure I see how this 
> improves the specs.

The Performance Timeline spec describes the interfaces to retrieve performance metric data and the object that all performance metrics extend. Resource Timing and User Timing specs require that data be retrieved and stored using the Performance Timeline API. 

Not only was the Navigation Timing spec (PerformanceTiming interface) written long before the Performance Timeline, as it had been shipped unprefixed in multiple browsers, we have found that developers have taken dependencies on it. We did not want to alter the PerformanceTiming interface for compatibility reasons, and instead decided to add a section in Performance Timeline spec (Section 4.4) to describe how the navigation data would work in the Performance Timeline.  For example, if you call performance.getEntries("navigation"), it would return a basic PerformanceEntry object with only four attributes: name="document", entryType="navigation", startTime=0, duration=loadEventEnd-0. 

We found that though this completes the timeline by including the navigation data, a developer could not retrieve the detailed timing data for each phase of the navigation from this object, like they could for resources and scripts. Instead a developer would be forced to use PerformanceTimeline for resources and scripts, and use performance.timing for navigation data. Further, Resource and User Timing were using higher resolution time than PerformanceTiming was. In order to make all of the performance metrics more consistent and balance compatibility, there has been discussions on creating a PerformanceNavigationTiming interface that would fully participate in the Performance Timeline and contain all the timing data in high resolution time. 

This discussion was started on the mailing list: http://lists.w3.org/Archives/Public/public-web-perf/2012Apr/0027.html. In our last call, we overwhelmingly felt that such changes would be better suited for the next version of the Navigation Timing spec, instead of living in the Performance Timeline spec which had been scoped to defining the uniform retrieval API and PerformanceEntry object. Hence, I have made the changes suggested in the mail thread to Navigation Timing 2 and have removed the section in Performance Timeline related to navigation data.

> Are we certain that the recent change to the spec (see above) is for the best? There should at least 
> be a fair chance to discuss the change before moving to CR.

The working group had spent much time discussing how to create a uniform interface for all performance metrics, which lead to the Performance Timeline spec. At least, Microsoft and Google feel very good with the current spec. Seeing that no issues had been raised against this spec during the Last Call phase and since then, the working group felt that it was time to move this spec to the next stage. This would be also be a good signal for us to start creating implementations.

However, if you believe there are spec issues that need to addressing, please do raise them.

Received on Friday, 27 April 2012 18:00:36 UTC

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