W3C home > Mailing lists > Public > public-web-perf@w3.org > August 2012

Re: Disparity between time bases in HighResolutionTime and ResourceTiming

From: James Simonsen <simonjam@chromium.org>
Date: Tue, 28 Aug 2012 18:52:34 -0700
Message-ID: <CAPVJQimLh43c=97sN4-Y=s-G48MgO_jCB-zpUV74a8jvrXL7Fw@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: public-web-perf <public-web-perf@w3.org>
On Tue, Aug 21, 2012 at 3:36 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  All Resource Timing attributes are defined as type DOMHighResTimeStamp.
> The High Resolution Time spec defines the DOMHighResTimeStamp as a type
> “used to store a time value measured relative to the navigationStart
> attribute of the PerformanceTiming interface [NavigationTiming], the start
> of navigation of the document, or a time value that represents a duration
> between two DOMHighResTimeStamps.”****
> ** **
> We had updated the definition of performance.now() and DOMHighResTimeStamp
> to be relative to the start of navigation of the document, not the root
> document, based on this discussion:
> http://lists.w3.org/Archives/Public/public-web-perf/2012Jun/0000.html.
> Essentially, this design doesn’t have the privacy leak issues and still
> allows comparing time with iframes by converting back to the unix epoch
> time base by adding performance.navigationStart to any DOMHighResTimeStamp
> value. We should not change this design for either High Resolution Time or
> the Timing specs.

Hmm... I'm not fully convinced. This is a very subtle thing for a web
developer to notice and it's not obvious how to use it correctly. I have a
couple of main complaints:

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.

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.

3. In order to compare values across iframes in script, you have to walk
the DOM to find the two NavigationTiming objects, then compute the delta
between them.

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.

Received on Wednesday, 29 August 2012 01:53:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:33 UTC