Re: Web Timing API

    I am forwarding some discussion brought up by Tim for more feedback. A
main take-away is
that, as it is right now, NavigationTiming is not capturing the timing of
DOM or innerHTML
replacement in the document body.

cheers,
Zhiheng

---------- Forwarded message ----------
From: Zhiheng Wang <zhihengw@google.com>
Date: Sun, Aug 8, 2010 at 10:29 PM
Subject: Re: Web Timing API
To: "Back, Tim" <tim.back@sap.com>


Hi, Tim,

    Sorry for not being able to get back to you sooner. Other stuff here got
my hands full and I haven't been able to attend
to the draft-related issues for the past week.

    We did look into having some sort of paint-related attribute in
WebTiming. Unfortunately, we found the paint events
from the browser have only rather loose correlation with what a user is
seeing on the UI and we haven't found out yet how
the browser can do this better than JS without adding too much overhead
inside it. One example is that Flash content
tends to introduce continuous paint events, which makes it difficult, if
possible, to decide which event reflects the rendering
of a complete user view.

    A alternative is the a "domInteractive", like the one in
document.readyState = interactiv. There is some ongoing discussion
about having this added to NavigationTiming in the WebPerf WG. I haven't
investigate much into the different between this and
what you are measuring right now but it seems to be one step closer to what
you are looking for.

   * Another interesting thing here is how your use case can be handled even
after the right variable is added. Assuming that you
are replacing document.body.innerHTML, currently NavigationTiming does not
necessarily capture timing for loading the replacement
content.

   I think all these are interesting points and should be brought to wider
audience on public-web-perf@w3.org.

cheers,
Zhiheng



On Wed, Aug 4, 2010 at 12:51 AM, Back, Tim <tim.back@sap.com> wrote:

>  Hello Zhiheng,
>
>
>
> I am a development architect at SAP responsible for browser related UI
> technologies. I just stumbled over you working draft of the Web timing API
> and I find it very interesting. I have been looking into how to measure
> browser performance for quite a while and have also read the 2 books by your
> colleague Steve Souders about web site performance.
>
>
>
> We have a number of HTML and JavaScript based frameworks at SAP. For the
> lack of better methods usually browser times are measured by monitoring the
> CPU time consumed by the browser process. As this doesn’t really give the
> correct picture in all cases (e.g. when the browser is busy applying some
> expensive filter in IE after an AJAX request was sent to a server and while
> the request is still being processed by the server, the consumed CPU doesn’t
> say anything about how long the user has to wait for a the response to be
> finished) we have also used the typical getTime method of JavaScript’s Date
> object. Some of our frameworks are AJAX based, so every request goes to the
> server via XMLHTTPrequest. The responses usually contain HTML parts which
> are then injected into the page using innerHTML replacements. With this
> there is usually no (un)load event but we can measure quite well
>
> ·         when a user action starts (e.g. when a button handler is
> invoked),
>
> ·         when the request is sent to the server (so we get the time
> immediately after invoking the XMLHTTPrequest send method),
>
> ·         when the response returns (we get the time when the
> onreadystatechange function is invoked)
>
> ·         when we finish the function that does the innerHTML replacements
>
>
>
> While the first 3 times seem pretty accurate, the 4th time tells us when
> DOM injection is finished, however this doesn’t necessarily mean that the
> browser has finished its (re)paint of the new HTML. I was thus always hoping
> the browser would have some event which is fired when the rendering engine
> is completely finished.  Or now with the Web timing API an attribute which
> tells us the exact time when the paint process is finished.
>
> I was wondering if you are also looking into this with respect to your work
> or is any of the attributes that you have defined already meant to yield
> this time?
>
>
>
> Thanks in advance for taking the time to read this!
>
>
>
> Best regards,
>
> Tim Back
>