Re: [WebTiming] HTMLElement timing

On Tue, Feb 2, 2010 at 10:36 AM, Zhiheng Wang <zhihengw@google.com> wrote:

> Hi, Olli,
>
> On Fri, Jan 29, 2010 at 6:15 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
>
>>  On 1/27/10 9:39 AM, Zhiheng Wang 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.
>>>
>>> cheers,
>>> Zhiheng
>>>
>>
>>
>> Like Jonas mentioned, this kind of information could be exposed
>> using progress events.
>>
>> What is missing in the draft, and actually in the emails I've seen
>> about this is the actual use case for the web.
>> Debugging web apps can happen outside the web, like Firebug, which
>> investigates what browser does in different times.
>> Why would a web app itself need all this information? To optimize
>> something, like using different server if some server is slow?
>> But for that (extended) progress events would be
>> good.
>> And if the browser exposes all the information that the draft suggest, it
>> would make sense to dispatch some event when some
>> new information is available.
>>
>
>    Good point and I do need to spend more time on the intro and use cases
> throughout
> the specs. In short, the target of this specs are web site owners who want
> to benchmark their
> user exprience in the field. Debugging tools are indeed very powerful in
> development but things
>  could become quite different once the page is put to the wild, e.g., there
> is no telling
> about dns, tcp connection time in the dev space; UGC only adds more
> complications to the
> overall latency of the page; and, "what is the right TTL for my dns record
> if I want to maintain
> certain cache hit rate?", etc.
>
>
>> There are also undefined things like paint event, which is
>> referred to in lastPaintEvent and paintEventCount.
>> And again, use case for paintEventCount etc.
>>
>
>    Something like Mozilla's MozAfterPaint?  I do need to work on more use
> cases.
>

In practice I think this will be useless.  In a page that has any sort of
animation, blinking cursor, mouse movement plus hover effects, etc the 'last
paint time' will always be immediately before the query.   I would recommend
dropping it.

- James


>
>>
>> The name of the attribute is very strange:
>> "readonly attribute DOMTiming document;"
>>
>
>    agreed... how about something like "root_times"?
>
>
>>
>>
>> What is the reason for timing array in window object? Why do we need to
>> know anything about previous pages? Or what is the timing attribute about?
>>
>
>   Something got missing in this revision, my bad. The intention is to keep
> previous pages' timing info only if these pages
> are all in a direction chain. From the user's perspective, the waiting
> begins with the fetching of the first page in a
> redirection chain.
>
>
> thanks,
> Zhiheng
>
>
>>
>>
>>
>> -Olli
>>
>
>