Re: [WebTiming] HTMLElement timing

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.


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