W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2011

Re: [Resource Timing] User feedback and a modified proposal

From: James Simonsen <simonjam@chromium.org>
Date: Thu, 26 May 2011 15:27:29 -0700
Message-ID: <BANLkTi=r3=UqKReevU9faiEuAFuDp8gpAg@mail.gmail.com>
To: public-web-perf <public-web-perf@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 May 2011 22:33:09 GMT