Re: [Web Timing] UserTiming

It would be good to add some context for why user timing is needed:

With Web 1.0 style pages the timing information provided by Navigation
Timing would be satisfactory for understanding the website's performance.
This isn't true for Web 2.0 style apps where the page is only loaded once.
And it's not possible for the browser to know what parts of a Web 2.0 app to
measure - open folder, send message, update friends list, etc. are phases of
the user experience that only the developer can identify. Therefore, we need
to give developers the tools to mark and measure these phases in Web 2.0
applications.


"mark" should return the time value for that mark. Ditto for
"markFullyLoaded" altho I propose we do away with that (see next item).

Wrt markFullyLoaded - I feel that there are going to be other milestones in
addition to "fully loaded" - start, first_byte, start_render, done_render,
etc. Creating a standalone function for each one of them is not good. What
if we have an enum that is used with mark()?

We need to think about usage patterns. The two issues I see are:
    1. web dev has to do a lot of subtraction: getMark("end_render") -
getMark("start_render")
    2. the timing info is in two locations (similar to Tony's point)
I like the simple API, but wonder if we should add a measure() function. In
which case the developer would do mark("render") and measure("render"). This
would produce a delta time called "render" in a new array of delta times.
The basis for this is that I believe most web devs want delta times sent
home, so we don't want them sending home epoch times (more bytes) and we
don't want them to have to do all the subtraction themselves.

This would be good to workout in the face to face meeting.

-Steve


On Mon, Oct 4, 2010 at 10:37 AM, Tony Gentilcore <tonyg@google.com> wrote:

> Looks great to me! I'm excited to see this happen.
>
> Some high level thoughts:
> 1. If a user calls mark("fullyLoaded"), they can later retrieve that
> with getMark("fullyLoaded"), but if they call markFullyLoaded(), they
> have to retrieve it with timing.fullyLoaded. This somehow doesn't seem
> intuitive to me. I don't have a great proposal, but some ideas:
>  - Call it setFullyLoaded() to set it appart from the others.
>  - Move markFullyLoaded() into timing.
>  - Cause it to both set timing.fullyLoaded and add a mark that is
> retrieve via getMarks().
> 2. For phoning home, a page will have to serialize both
> performance.timing and performance.getMarks(). Perhaps we could solve
> #2 and make the whole thing easier to use by exposing a map of marks
> under timing right along with the built-in marks. For instance:
>  timing {
>    navigationStart : 123,
>    fetchStart : 123,
>    ...
>    marks : {
>      userMarkA : 123,
>      userMarkB : 123
>    }
>  }
> 3. Something feels odd about the fact that I can call mark("foo")
> multiple times and have multiple entries show up in getMarks(), but if
> I call getMark("foo"), I only get a single number instead of a list.
> My recommendation is to only return the most recent time per key in
> getMarks(). But if we think it is a valuable feature to allow multiple
> times per key, then getMark() needs to return a list.
>
> And a few comments/questions on trivial details:
> 1. It looks like in the IE9 implementation getMarks() can be called
> with no arguments to retrieve all marks, but I don't see that in the
> spec.
> 2. Which namespace does this fall under? I assume window.performance
> based on the IE9 beta implementation. If so, the spec should say
> "[Supplemental] interface Performance" instead of "interface
> UserTiming".
> 3. Typo: two interfaces are named DOMPerformanceTimingList, the second
> looks like it should be DOMPerformanceTiming.
> 4. I'd like to reconsider the interface names as a whole to get a
> consistent scheme. IE doesn't expose __proto__, but other user agents
> do. Right now we have Performance, NavigationTiming, NavigationInfo
> (from Navigation Timing spec) and UserTiming, DOMPerformanceTiming,
> DOMPerformanceTimingList (from User Timing spec). While this isn't
> what WebKit currently implements, this might be a good scheme:
> DOMPerformance, DOMPerformanceTiming, DOMPerformanceNavigation,
> DOMPerformanceMark, DOMPerformanceMarkList. But I'm open to any scheme
> that is internally consistent.
>
> -Tony
>
> On Fri, Oct 1, 2010 at 8:07 PM, Anderson Quach <aquach@microsoft.com>
> wrote:
> > Hi All,
> >
> >
> >
> > I’ve added the first draft copy of the UserTiming [1] spec to webperf
> > repository.  The problem with using new Date() to capture timing
> information
> > for custom scenarios relies on the accuracy of the timer within the user
> > agent.
> >
> >
> >
> > Building on the 1ms precision called out in Navigation Timing,  this
> > specification defines an interface for web applications to capture timing
> > information with a developer supplied name. The user agent captures the
> time
> > stamp at the point and time specified in the code executing in the user
> > agent.
> >
> >
> >
> > [1]
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/UserTiming/Overview.htm
> >
> >
> >
> > Regards,
> >
> > Anderson Quach
> > IE Program Manager
>
>