- From: James Simonsen <simonjam@chromium.org>
- Date: Thu, 26 May 2011 15:27:29 -0700
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <BANLkTi=r3=UqKReevU9faiEuAFuDp8gpAg@mail.gmail.com>
On Thu, May 26, 2011 at 7:14 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote: > On Wed, 01 Dec 2010 13:57:13 +0100, Sigbjørn Vik <sigbjorn@opera.com> > wrote: > > We should also explicitly lay out in the spec how future extensions should >> be included, e.g. time to compile script into machine code, Flash setupTime. >> Using vendor prefixes, in which locations on which objects, which objects >> should not be allowed to be touched, etc. >> > > I am bringing this back to the table, I cannot see that we've reached a > conclusion on this one. This holds equally for Navigation Timing as for > Resource Timing. There are many more use cases than the above, including > some timings that are highly implementation specific, and not fit for > standardization. > Yeah, I really think we should lay out a roadmap for future additions. I've heard people talk about script parsing and execution time, first paint timing, and WebGL timing. We should anticipate that new features like these will be added and have a rough idea how we'd handle them. It's not clear whether these should piggyback on existing specs or have their own interface. I think we should have a plan for where we want to put things in the performance namespace too. Right now, there's a fair amount of inconsistency. If we were to implement everything spec'd right now, we'd have: interface Performance { # Navigation Timing readonly attribute PerformanceTiming timing; readonly attribute PerformanceNavigation navigation; # Resource Timing void clearResourceTimings(); PerformanceResourceTimingList getResourceTimings(); PerformanceResourceTimingList getResourceTimingsByURL(in DOMString url); void setResourceTimingBufferSize (in unsigned long maxSize); attribute Function onresourcetimingbufferfull; # User Timing const string MARK_FULLY_LOADED = "fullyLoaded"; const string MARK_FULLY_VISIBLE = "fullyVisible"; const string MARK_ABOVE_THE_FOLD = "aboveTheFold"; const string MARK_TIME_TO_USER_ACTION = "timeToUserAction"; void mark(in DOMString markName); Array getMarks(in optional DOMString markName); void clearMarks(in optional DOMString markName); void measure(in DOMString measureName, in optional DOMString startMark, in optional DOMString endMark); Array getMeasures(in optional DOMString measureName); void clearMeasures(in optional DOMString measureName); }; It doesn't look very well designed now. Navigation Timing has its own namespaces, but "timing" is ambiguous with the rest. Resource Timing has its own name in every method. User Timing adds a bunch of constants in the top-level namespace. User Timing doesn't group related marks, unlike the others. If we set a clear pattern now, it'll be easier for new specs, since they can just follow the same pattern. James
Received on Thursday, 26 May 2011 22:33:06 UTC