RE: Disparity between time bases in HighResolutionTime and ResourceTiming

On Tue, Aug 28, 2012 at 6:53 PM, James Simonsen wrote:
> 1. We really don't want people mixing high res times and UNIX times. That's why 
> now() starts at 0 instead of starting from the same value as timing.navigationStart. 
> It seems like a bad idea to encourage them to do that, but only in this one specific use case.

I believe having the ability to convert between the time bases is desirable. We designed the origin of the High Resolution Time to be at time 0, the start of navigation of the document, for ease of readability, keeping the focus on time since the beginning of the document and freeing up bits to provide additional precision. However, if we don't evangelize a way to take High Res Time to Unix time, one can't really determine the calendar time using performance.now(). E.g., what if I want to know the current calendar time in sub-millisecond resolution? What if I want to compare performance.now() time stamps from two different browsing sessions? This approach keeps it simple; you just add performance.navigationStart.

> 2. When Navigation Timing 2 is complete, all timing data will be available through the Performance 
> Timeline API. However, if your site has iframes, you'll also need to ping back timing.navigationStart 
> for each document.

Yes you can, but I don't know if that will be necessary. Each sub-document's Navigation Timing 2 and Resource Timing will appear independent of the root document; they all start at time 0. However, no data is lost as each sub-document will be represented in the root document's Resource Timing in its correct order.

> It seems like it'd be so much easier if everything "just worked" from the web developers 
> perspective: now() would be the same across (same-origin) iframes, and they could just 
> concatenate the JSON PerformanceEntryLists from each iframe to build a timeline.

Unfortunately, this suggestion creates a privacy leak situation and need additional complexity to try to fix the leak.

Further, wouldn't this suggested change complicate the otherwise simple timeline for each sub-document? In the current model, each sub-document's Navigation Timing 2 or Resource Timing begins at its time 0. With this proposal, they would all begin at their root document's navigationStart; meaning the sub-document's timeline will be shifted out. If the sub-documents are dynamically added, this could mean a very shifted sub-document timeline. Seems like another unnecessary complication.

Let's chat on the call.

Jatinder

Received on Wednesday, 29 August 2012 16:58:46 UTC