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

Re: [WebTiming] HTMLElement timing

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 27 Jan 2010 17:57:52 -0800
Message-ID: <63df84f1001271757n2e19af25je2f16cb1d0f99456@mail.gmail.com>
To: Zhiheng Wang <zhihengw@google.com>
Cc: public-webapps@w3.org
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.

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

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

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

>> 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 :)

/ Jonas
Received on Thursday, 28 January 2010 01:58:46 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:22 UTC