RE: Simplified Resource Timing and User Timing

Based on feedback from James Simonsen and Tony Gentile, I have made the following spec update:


1.      Removed "id" attribute and getResourceTimingsById method from Resource Timing.

As per James' remarks, the "id" attribute doesn't always make sense for some resources, like CSS or plugin subresources. Further, "id" is a snapshot at a given time, which may change and may not be unique. In an effort to not confuse users, this attribute and its associated method have been removed from the spec, http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html..



I have not yet made this spec update due to timing, but I am ok with making this change:



2.      Remove all measure methods from User Timing.

In an effort to keep the interface simple, we can remove all measure methods (measure(), getMeasures(), clearMeasures()). Though, these methods do provide a convenient way to measure the time between two marks and was endorsed by Steve Souders as a good practice, this work can be implemented by a web developer or an external library.


I have not made the following updates for the reasons listed below:


1.      Removing "type" attribute and getResourceTimingsByType method from Resource Timing.

The "type" attribute and getResourceTimingsByType method provide users with a simple way to roughly sort their resource timing data by the initiator types. As some initiators, like XHR and Script, can load additional resources, it is useful and practical for web developers to sort their resources by the type of initiator. The initiator type will not change over time. The "type" attribute doesn't suffer from the problems of the "id" attribute and has specific value to web developers.



2.      Requiring Resource Timing to be explicitly enabled by web developers.

We have evaluated and closed on this concern in the past on the mailing threads and calls. Our joint analysis, http://lists.w3.org/Archives/Public/public-web-perf/2010Dec/0024.html, had shown that the impact of keeping Resource Timing enabled is negligible. The average number of resources per page is 42 and the 90th percentile is 145. The benefit of having Resource Timing enabled by default will mean that web pages using analytics libraries will have to make no explicit change to use Resource Timing. Otherwise, all analytic library users will have to explicitly update their pages to enable Resource Timing and this will hurt adoption of this API. Further, for sites that do not wish to gather or use this data, we already have the ability to disable Resource Timing data gathering by using setResourceTimingBufferSize method to reduce the buffer size to 0.

Thanks,
Jatinder

Jatinder Mann | Internet Explorer