RE: [HighResolutionTime] performance.now() value depends on the document, which can cause problems

On 5/31/12 2:27 AM, Jonas Sicking wrote:
>> A shared timebase per origin and a non-zero navigationStart on 
>> subframes might just be the best solution.
>
> I like that solution.
>
> That also has the advantage in that it allows doing cross-frame performance 
> measurements. I.e. you can check when the various steps of a sub-document 
> load happen in relation to the top-level document load.
> This can be useful since often a page which visually looks like one document, 
> might actually be comprised of several frames.
>
> One very concrete use-case would be seeing when the various stages of an 
> ad which is loaded in an iframe happen in relation to both each other, and in 
> relation to the top-level document which the user is seeing.

To do cross-frame measurements in the current design, one only needs to add performance.timing.navigationStart to performance.now() to get a common, globally comparable, high-resolution timestamp measured from Jan 01 1970. This approach doesn't require caching the parent's performance.timing.navigationStart.

On Wed, May 30, 2012 at 10:19 AM, Tony Gentilcore <tonyg@google.com> wrote:
> There's another tradeoff: it's desirable for now() to be comparable to 
> the values returned by performance.timing. For instance, a child frame 
> calling now() in the load event should get a value similar to 
> "performance.timing.loadEventStart - 
> performance.timing.navigationStart".
> ...
> Jatinder, what does IE do here?

Adding performance.timing.navigationStart to performance.now() will let you compare directly with the other performance.timing attributes. E.g., performance.now() + performance.timing.navigationStart in the child frame's load event will give you a value similar to performance.timing.loadEventStart. I think we should add a note in the High Resolution Time spec making it clear that such comparisons can be made in this way. To your other question, IE10 Release Preview shipped with the design currently documented in the spec.

The above technique also works in cross-origin iframes without additional complexities. Whereas, a timebase origin based on the top level browsing context's performance.timing.navigationStart would allow a cross-origin iframe to tell how long the parent has been alive, which we agreed wasn't a good idea - http://lists.w3.org/Archives/Public/public-web-perf/2012Feb/0098.html. 

Even using a shared timebase per origin adds complexities to the Timing designs. Currently, the Performance Timeline (Navigation Timing 2, Resource Timing and User Timing) for each sub-document is based on the start of navigation of that document, which creates a timeline view starting from zero. With the suggested approach, all sub-document timelines will be shifted out. Whereas before each attribute in the Performance Timeline returned a delta from its document's start, now one would have to take the difference from their startTime attribute to get that same information, depending on if it's a frame or not (or just be forced to always take the difference). Dynamically added frame's timeline view may get pushed out significantly, potentially causing confusion to someone analyzing their data that didn't know their page was in a frame. 

This proposal would also make it hard to make some timing based assumptions. For example, if a site uses performance.now() to make a timing based assumptions, those assumptions could change on whether it is loaded in an iframe of same or different origin than its parent, if it is loaded in a iframe of different origin than its parent and another iframe of the same origin was added before it or not, etc. The current model doesn't have this issue.

The current design solves the cross frame measurements issue raised and it's a simpler model (time did not exist before I did not exist). We should keep the design as is.

Thanks,
Jatinder

Received on Saturday, 2 June 2012 17:57:49 UTC