Re: [WebTiming] HTMLElement timing

Hi, James,

    Good point indeed. Some evaluation has been done here with camstudio.
Using paint event
helps in many cases but, for the reasons you mentioned, it's not yet
reliable enough. So if it's
worthwhile to do it in this spec is indeed debatable.

   A related question and one that many of us have been trying to figure
out: if we need one single
metric to benchmark a user's latency experience on a web page, what it
should be? onload is no
longer living up to its reputation these days. Any thought to share on that?

  It's very exciting to have all the feedback and I've learned something
everytime. Thanks to all.

cheers,
Zhiheng


On Tue, Feb 2, 2010 at 12:44 PM, James Robinson <jamesr@google.com> wrote:

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