Re: [PerformanceTimeline] Returning Navigation Timing attributes in High Resolution Time

Sorry I missed the call this week.

I'd rather go the other way. I want to encourage developers to use
PerformanceTimeline for everything and discourage the use of
PerformanceTiming. It's unfortunate we shipped them in the wrong
order. From my perspective, window.performance.timing is deprecated and we
shouldn't change it.

I think it's easier for users to know how to use one API to get all their
timing data, rather than trying to mix and match. An example of this is
that it'll be easier for developers to extract a waterfall view of the page
load. They'll just make one call to getEntries(), dump to JSON, and upload
with XHR. Navigation Timing is critical to making sense of the waterfall,
so it'd be a bummer if they had to manually augment their JSON with
window.performance.timing.

I also think it's useful to be able measure between resources and the main
document. One of the use cases we'd discussed long ago is the idea of a
page with a single critical resource. This is something like a main.js file
that makes the web app go. Developers of such apps would want to see when
that loads relative to what's happening in the main document.

On Wed, Apr 11, 2012 at 9:46 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  I recommend we keep the spec as is. We already have done a good job of
> including Navigation Timing within the timeline in the Performance Timeline
> spec.
>

I don't understand this statement. It's not in there at all, right? Just
that 0 is navigation start via the high res times.

James