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

> The PerformanceTiming interface in the Navigation Timing Spec is inconsistent with the 
> PerformanceResourceTiming Interface in the Resource Timing spec. To fix this, a new interface,
> the PerformanceNavigationTiming interface, was suggested. (To replace or complement the 
> PerformanceTiming interface?)

Yes. We designed the getEntries, getEntriesByType and getEntriesByName methods to be a single API that can be used to retrieve any performance metric. Though PerformanceResourceTiming of the Resource Timing spec and PerformanceMarks and PerformanceMeasures of the User Timing spec objects can be retrieved from those methods, PerformanceTiming cannot. PerformanceTiming is exposed on performance.timing rather than be returned as an object.

To ensure that PerformanceTiming data can be obtained using those retrieval methods, we are proposing a PerformanceNavigationTiming object that would be returned when using those methods. It would returns the same data that PerformanceTiming interface would, except in sub-millisecond resolution.

> Now, because of historical reasons and compatibility issues, the PerformanceNavigationTiming 
> interface is being removed from the current set of specs, and pushed to the future. (Appearantly 
> we have planned a new, future spec, Navigation Timing 2.)

The PerformanceNavigationTiming interface was never proposed in the current set of specs; it was first proposed in Navigation Timing 2. Section 4.4 of Performance Timeline just stated that when calling getEntries("navigation") to return an object with the name, entryType, startTime and duration of the navigation, not the individual attributes.

> If we for a second ignore the compatibility issues, wouldn't the proper way to fix this be by writing 
> the specs the way they ought to be, as none of them are final yet? And if we do care about compatibility, 
> will we not get even bigger compat problems if we ship a spec now which we know will be incompatible 
> with version 2? If we have a solution for fixing such issues for version 2, why don't we just use that solution now?

The Working Group chatted about this option in our last call. The key difference here is that PerformanceTiming data is not incompatible with PerformanceNavigationTiming; the data is just retrieved differently. One lives on performance.timing, whereas the other is obtained using the getEntries* methods. Additionally, the PerformanceTiming data is in milliseconds, whereas PerformanceNavigationTiming is in sub-millisecond, the data can still be compared against each other. 

As PerformanceNavigationTiming is returned as an object, adding it will not pollute the performance namespace any further.

Considering PerformanceTiming has been shipped and is being used by real developers and that the new interface doesn't significantly change the data, the Working Group felt that this was best to standardize Navigation Timing and make the new changes in the next version of the spec. One immediate benefit is that developers can rely on the implementations of PerformanceTiming to be interoperable.

> Regarding moving specs to CR, I believe (as a general principle) that one should not move to CR immediately 
> following a major edit (such as deleting an entire section), as issues such as the above might appear, and we 
> should allow ourselves time to discuss such issues.

We don't expect the spec to move to CR until at least next week, which would be two weeks after the changes were made. Would you like us to move CR out another two weeks?

Thanks,
Jatinder

Received on Tuesday, 1 May 2012 22:51:23 UTC