Re: [WebTiming] HTMLElement timing

On Wed, Jan 27, 2010 at 5:57 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Jan 27, 2010 at 5:30 PM, Zhiheng Wang <zhihengw@google.com> wrote:
> > Hi, Jonas,
> >    Thanks for the comments. pls find comments inline.
> > On Wed, Jan 27, 2010 at 12:12 AM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>
> >> On Tue, Jan 26, 2010 at 11:39 PM, Zhiheng Wang <zhihengw@google.com>
> >> wrote:
> >> > Folks,
> >> >      Thanks to the much feedback from various developers, the
> WebTiming
> >> > specs has undergone some
> >> > major revision. Timing info has now been extended to page elements and
> a
> >> > couple more interesting timing
> >> > data points are added. The draft is up
> >> > on http://dev.w3.org/2006/webapi/WebTiming/
> >> >      Feedback and comments are highly appreciated.
> >>
> >> I take it the idea is that you can get when we for an <img> element
> >> start fetching the image, when image data starts arriving etc. I'd
> >> prefer if the spec had a comprehensive list of elements that this is
> >> expected to be implemented on.
> >
> >    Right now only embedded content elements require these info. An
> explicit
> > list
> > might be better though, e.g., <script> is not classified as embedded
> > content.
>
> What do these properties measure on a <figure>? And why would you care
> to measure downloading performance on <link rel=icon>? And why
> wouldn't you care about <script>? That one seems more performance
> critical than any other external resource.
>

    sorry for not making it clearer. What I meant is having a explicit list
of elements
makes sense. <script> is an interesting one. It might warrant its own
properties like
execution time.

    You got a good point about some properties are meaningless in some cases
and I've
been figuring how to make the interfaces better. Some suggested a free-form
key-value
type but I am not sure how much different it makes in terms of conformance
testing. Any
suggestion?



>
> >> Extending this to elements introduces *significantly* more
> >> implementation cost. Is it really worth it? My concern is that this
> >> spec already had fairly high cost/benefit ratio since it doesn't add
> >> any "new" functionality to the web platform, it "just" lets devs do
> >> more accurate performance measurements. And it's far from easy to
> >> implement since much of the information isn't available outside of the
> >> networking code (and many times there only available on a different
> >> thread).
> >
> >    Certainly the overhead of implementing the specs should be evaluated.
> It
> > should be
> > done while we are looking into more browser-specific implementations.
> Right
> > now I want
> > to be as specific as possible in the specs. But much implementation
> overhead
> > can be
> > avoided if we can tune the specs to accept some slight "inaccuracy", say,
> > taking the time
> > of the first callback from the data socket instead of the actual first
> > byte time as responseStart.
>
> I'm not sure what you mean by "more browser-specific implementations"?
> Implementation complexity vs. value should be looked at all the time
> IMHO.
>

    We are actively working with some browser developers to have these
interfaces
implemented but I suspect the implementation complexity varies in different
browsers.
We will get some more idea once we step further. On the other hand, these
timing info
are very valuable in benchmarking page performance. Right now developers are
either
getting only partial data or have to relying on their own plug-in to get to
these info.
Not all the developers are doing the measurements right now probably because
these
interfaces are not available to everyone. :-)


>
> >> Also, what is the use case for the "Ticks" interface?
> >
> >    The Ticks interface is a convenient way to store time measurements and
> > retrieve it later on a page.
> > I will have some example there.
>
> Why not just do:
> myTimings = {};
> myTimings.fooStart = new Date();
>
> etc? Javascript has perfectly good ways to store values already.
>

    window.timing property keeps timing info of previous navigation as well
so the Tick
interface also provides a way to pass custom POI to the next page. Some
security
measure need to be added later though.


>
> >> I would really encourage that this spec be reduced to the most
> >> important parts first and wait for browsers to catch up before adding
> >> "nice to have" features.
> >
> >    Agree and we do keep that in mind. Most of the the properties
> specified
> > right now are
> > on the critical path of user perceived latency though.
>
> That surprises me. See my first answer above.
>

    I meant these properties are in the latency critical path of the element
it belongs to...



>
> >> If implementations implement progress events on the various elements
> >> it would seem like you would get most of the advantages from this
> >> spec.
> >
> >    The progress events are great, except that they mostly focus on
> > downloading the content but
> > not much about everything else, say, parseStart.
>
> Specs can be changed, nothing is set in stone :)
>

    Good to know. :-) Having more data exported in the progress events will
be
good news to those performance debugging tools. When collecting latency
field data, many developers perfer to fetch all timing info of an
element (window.document?)
at once and send a json object.

thanks,
Zhiheng


>
> / Jonas
>