W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [WebTiming] HTMLElement timing

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 29 Jan 2010 00:50:24 -0800
Message-ID: <63df84f1001290050q2fe3aecl4106014a36520696@mail.gmail.com>
To: Zhiheng Wang <zhihengw@google.com>
Cc: public-webapps@w3.org
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();

>> >> 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.

/ Jonas
Received on Friday, 29 January 2010 08:58:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT