- From: Tony Gentilcore <tonyg@google.com>
- Date: Mon, 4 Oct 2010 10:37:46 -0700
- To: Anderson Quach <aquach@microsoft.com>
- Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
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
Received on Monday, 4 October 2010 17:39:14 UTC