Re: [WebTiming] HTMLElement timing

Jonas,

On Fri, Jan 29, 2010 at 12:50 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Jan 28, 2010 at 10:53 PM, Zhiheng Wang <zhihengw@google.com>
> wrote:
>
> >> >> 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.
>
> Sounds like simply using
>
> sessionStorage.myTimings = {};
> sessionStorage.myTimings.fooStart = new Date();
>

  right. Tick() is indeed supposed to be a thin wrapper around the web
storage.
Now come to think of it, I tend to agree that it is probably not worthy
putting in the spec.
Thanks for the catch.



>
> >> >> 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
>
> While I agree that timing information is important, I don't think it's
> going to be so commonly used that we need to add convenience features
> for it. Adding a few event listeners at the top of the document does
> not seem like a big burden.
>

    User latency is quite sensitive to scripts at the top of the page.
And it would be really bad if the measurement instrumentations themselves
would much slow down the page. :-) Also, event listeners might not work in
some corner cases (meta-refresh redirection?) Last, some (probably minor)
concerns rise from the discrepancies between a natively recorded timestamp
and that done in a js callback.


thanks,
Zhiheng



> / Jonas
>