New mailing list for Web Performance

[Zhiheng Wang]

Hello, folks,

   While the official announcement will come later, I would like to give a
heads-up about
a new mailing list,
public-web-p...@w3.org.
This
mailing list will focus on discussion related
to Web performance, including the
WebTimingdraft.

   Good day!

cheers,
Zhiheng

[WebTiming] Updates

[Zhiheng Wang]

Hello,

An updated version of the WebTiming draft is up on
http://dev.w3.org/2006/webapi/WebTiming/
Some of the changes per feedbacks:
* the timing attributes are now under the window.performance name space
* most of the sensitive timing information have been removed from
ResourceTiming
* ResourceTiming is now exposed through
ResourceTimingCollector/ResourceTimingEvent

   There are also some potential changes that I believe to be benefit from
discussion with more folks here
on the list.
   * when resource is fetched from the cache, some operations like DNS and
tcp handshake will not happy.
  In that case, the corresponding attributes are set to zero. Does it
provide any benefit if we fill them
  with the closest timestamp from other valid attributes?

   * How useful it would be to provide two more interface, namely
getCompactTiming() and getTimingMeasures()?
  getCompactTiming() returns a stringified NavigationTiming object with
all the attribute names replaced with
 a compact ones. getTimingMeasures() gives out durations of the timing
info instead of epoch time, e.g.,
 domainLookup (= domainLookupEnd - domainLookupStart).

   As always, feedbacks/comments please.

cheers,
Zhiheng

[WebTiming] Exporting flattened DOMTiming data

[Zhiheng Wang]

   Discussions with several browser developers suggest exporting a flattened
data structure containing
all the DOMTiming objects on the page. Doing so allows site developers to
send the all the timing information
back for analysis without travelling the entire DOM tree. It helps minimize
the observer effect of the client
side instrumentations.

  The current proposal is to add an additional interface to the
WebTimingdraft that exports
this block of
timing data, including the url, type and probably id associated with each
DOMTiming object. The implementation
details are mostly left to UAs at this time.

  Another question is should this flattened data contain only DOMTiming
objects currently in the DOM or all those
ever exist since the page starts. My preference is the first case but it's
up to debate.

  I imagine this to be a rather significant change in terms of UA
implementations so I would like to bring
this up for discussion.

cheers,
Zhiheng

Re: [WebTiming] HTMLElement timing

[Zhiheng Wang]

Hi, James,

On Wed, Feb 17, 2010 at 10:36 PM, James Robinson  wrote:

> A few more questions:
>
> * What should the values of domainLookupStart/domainLookupEnd be if the DNS
> lookup was served out of cache?
>

   It should be the time before/after the retrieval of the cached entry. The
latency for that is usually quite small from what
I've seen in IE before, e.g., a msec or two, but it depends on the load of
the time.



> What about if the DNS resolution started before the fetch was initiated
> (i.e. if DNS prefetching is used or if the resource shares a domain with
> another resource that was fetched earlier)?
>

   Usually the prefetch is to get another object or just a 204, so I think
it makes sense to treat future DNS lookup as from cache?

   A question for browser gurus: is the connection reuse based on domain or
ip? I presume it's on domain but I'd like to make sure.



>
> * The specification requires that "The granularity and accuracy of the
> timing-related attributes in the DOMTiming and navigationTiming interface
> must be no less than one millisecond."  This is not generally possible on
> Windows due to the inaccuracy of system-provided timing APIs.  Could you
> relax this requirement so that it's possible to implement a compliant UA on
> all systems?
>

Thanks for bring this up. By saying that, I was hoping some sort of
fine-granularity timer was provided on window rather than the
system clock. But if that proves to be impossible or inefficient, dropping
it sounds like the way to go.



>
> * What precisely does 'parse' time mean for each element?  For example, on
> a 

Re: [WebTiming] HTMLElement timing

[Zhiheng Wang]

FYI, I just made some minor updates to the draft based on the
discussion, like removing Ticks() and
narrowing down the list of elements that should provide the DOMTiming
interface. I am going to throw
in more details shortly as well.

thanks,
Zhiheng

On Tue, Feb 2, 2010 at 1:09 PM, lenny.rachitsky <
lenny.rachit...@webmetrics.com> wrote:

> I’d like to jump in here and address this point:
>
> “While I agree that timing information is important, I don't think it's
> going to be so commonly used that we need to add convenience features
> for it. Adding a few event listeners at the top of the document does
> not seem like a big burden.”
>
> I work for a company that sells a web performance monitoring service to
> Fortune 1000 companies. To give a quick bit of background to the monitoring
> space, there are two basic ways to provide website owners with reliable
> performance metrics for their web site/applications. The first is to do
> active/synthetic monitoring, where you test the site using an automated
> browser from various locations around the world, simulating a real user.
> The
> second approach is called passive or real user monitoring, which captures
> actual visits to your site and records the performance of those users. This
> second approach is accomplished with either a network tap appliance sitting
> in the customers datacenter that captures all of the traffic that comes to
> the site, or using the “event listener” javascript trick which times the
> client side page performance and sends it back to a central server.
>
> Each of these approaches has pros and cons. The synthetic approach doesn’t
> tell you what actual users are seeing, but it consistent and easy to
> setup/manage. The appliance approach is expensive and misses out on
> components that don’t get served out of the one datacenter, but it sees
> real
> users performance. The client side javascript timing approach gives you
> very
> limited visibility, but is easy to setup and universally available. This
> limited nature of the this latter javascript approach is the crux of why
> this “Web Timing” draft is so valuable. Website owners today have no way to
> accurately track the true performance of actual visitors to their website.
> With the proposed interface additions, companies would finally be able to
> not only see how long the page truly takes to load (including the
> pre-javascript execution time), but they’d also now be able to know how
> much
> DNS and connect time affect actual visitors’ performance, how much of an
> impact each image/objects makes (an increasing source of performance
> issues), and ideally how much JS parsing and SSL handshakes add to the load
> time. This would give website owners tremendously valuable data is
> currently
> impossible to reliably track.
>
>
> Lenny Rachitsky
> Webmetrics
>
>
> James Robinson-5 wrote:
> >
> > On Tue, Feb 2, 2010 at 10:36 AM, Zhiheng Wang 
> wrote:
> >
> >> Hi, Olli,
> >>
> >> On Fri, Jan 29, 2010 at 6:15 AM, Olli Pettay
> >> 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 informati

Re: [WebTiming] HTMLElement timing

[Zhiheng Wang]

   Somehow Lenny's comments got lost from the list.

On Tue, Feb 2, 2010 at 10:57 AM, Lenny Rachitsky <
lenny.rachit...@webmetrics.com> wrote:

>  I’d like to jump in here and address this point:
>
> “While I agree that timing information is important, I don't think it's
>
> going to be so commonly used that we need to add convenience features
> for it. Adding a few event listeners at the top of the document does
> not seem like a big burden.”
>
> I work for a company that sells a web performance monitoring service to
> Fortune 1000 companies. To give a quick bit of background to the monitoring
> space, there are two basic ways to provide website owners with reliable
> performance metrics for their web site/applications. The first is to do
> active/synthetic monitoring, where you test the site using an automated
> browser from various locations around the world, simulating a real user. The
> second approach is called passive or real user monitoring, which captures
> actual visits to your site and records the performance of those users. This
> second approach is accomplished with either a network tap appliance sitting
> in the customers datacenter that captures all of the traffic that comes to
> the site, or using the “event listener” javascript trick which times the
> client side page performance and sends it back to a central server.
>
> Each of these approaches has pros and cons. The synthetic approach doesn’t
> tell you what actual users are seeing, but it consistent and easy to
> setup/manage. The appliance approach is expensive and misses out on
> components that don’t get served out of the one datacenter, but it sees real
> users performance. The client side javascript timing approach gives you very
> limited visibility, but is easy to setup and universally available. This
> limited nature of the this latter javascript approach is the crux of why
> this “Web Timing” draft is so valuable. Website owners today have no way to
> accurately track the true performance of actual visitors to their website.
> With the proposed interface additions, companies would finally be able to
> not only see how long the page truly takes to load (including the
> pre-javascript execution time), but they’d also now be able to know how much
> DNS and connect time affect actual visitors’ performance, how much of an
> impact each image/objects makes (an increasing source of performance
> issues), and ideally how much JS parsing and SSL handshakes add to the load
> time. This would give website owners tremendously valuable data is currently
> impossible to reliably track.
>
> --
> Lenny Rachitsky
> Neustar, Inc. / Software Architect/R&D
> 9444 Waples St., San Diego CA 92121
> Office: +1.877.524.8299x434 / lenny.rachit...@webmetrics.com /
> www.neustar.biz
>
> On 2/2/10 10:36 AM, "Zhiheng Wang"  wrote:
>
> Hi, Olli,
>
> On Fri, Jan 29, 2010 at 6:15 AM, Olli Pettay 
> 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?", 

Re: [WebTiming] HTMLElement timing

[Zhiheng Wang]

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

>
>
> On Tue, Feb 2, 2010 at 10:36 AM, Zhiheng Wang  wrote:
>
>> Hi, Olli,
>>
>> On Fri, Jan 29, 2010 at 6:15 AM, Olli Pettay 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
>>>
>>
>>
>

Re: [WebTiming] HTMLElement timing

[Zhiheng Wang]

Jonas,

On Fri, Jan 29, 2010 at 12:50 AM, Jonas Sicking  wrote:

> On Thu, Jan 28, 2010 at 10:53 PM, Zhiheng Wang 
> wrote:
>
> >> >> 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.
> >
> > window.timing property keeps timing info of previous navigation as
> well
> > so the Tick
> > interface also provides a way to pass custom POI to the next page. Some
> > security
> > measure need to be added later though.
>
> Sounds like simply using
>
> sessionStorage.myTimings = {};
> sessionStorage.myTimings.fooStart = new Date();
>

  right. Tick() is indeed supposed to be a thin wrapper around the web
storage.
Now come to think of it, I tend to agree that it is probably not worthy
putting in the spec.
Thanks for the catch.



>
> >> >> 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.
> >
> > I meant these properties are in the latency critical path of the
> element
> > it belongs to...
> >
> >>
> >> >> 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 :)
> >
> > Good to know. :-) Having more data exported in the progress events
> will
> > be
> > good news to those performance debugging tools. When collecting latency
> > field data, many developers perfer to fetch all timing info of an
> > element (window.document?)
> > at once and send a json object.
> > thanks,
> > Zhiheng
>
> While I agree that timing information is important, I don't think it's
> going to be so commonly used that we need to add convenience features
> for it. Adding a few event listeners at the top of the document does
> not seem like a big burden.
>

User latency is quite sensitive to scripts at the top of the page.
And it would be really bad if the measurement instrumentations themselves
would much slow down the page. :-) Also, event listeners might not work in
some corner cases (meta-refresh redirection?) Last, some (probably minor)
concerns rise from the discrepancies between a natively recorded timestamp
and that done in a js callback.


thanks,
Zhiheng



> / Jonas
>

Re: [WebTiming] HTMLElement timing

[Zhiheng Wang]

Hi, Olli,

On Fri, Jan 29, 2010 at 6:15 AM, Olli Pettay 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
>

Re: [WebTiming] HTMLElement timing

[Zhiheng Wang]

On Wed, Jan 27, 2010 at 5:57 PM, Jonas Sicking  wrote:

> On Wed, Jan 27, 2010 at 5:30 PM, Zhiheng Wang  wrote:
> > Hi, Jonas,
> >Thanks for the comments. pls find comments inline.
> > On Wed, Jan 27, 2010 at 12:12 AM, Jonas Sicking 
> wrote:
> >>
> >> On Tue, Jan 26, 2010 at 11:39 PM, 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.
> >>
> >> I take it the idea is that you can get when we for an  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., 

Re: [WebTiming] HTMLElement timing

[Zhiheng Wang]

Hi, Jonas,

   Thanks for the comments. pls find comments inline.

On Wed, Jan 27, 2010 at 12:12 AM, Jonas Sicking  wrote:

> On Tue, Jan 26, 2010 at 11:39 PM, 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.
>
> I take it the idea is that you can get when we for an  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<http://dev.w3.org/html5/spec/Overview.html#embedded-content-1>
require
these info. An explicit list
might be better though, e.g., 

[WebTiming] HTMLElement timing

[Zhiheng Wang]

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

Re: RFC: WebApp Timing (Rnd 2)

[Zhiheng Wang]

Hi, Anne,
Thanks for the comments and I will address them in the next revision.
Pls see details inline.

On Mon, Sep 28, 2009 at 6:28 AM, Anne van Kesteren  wrote:

> On Sat, 26 Sep 2009 23:17:06 +0200, Zhiheng Wang 
> wrote:
>
>> Updated to incorporate the feedbacks. (Sorry for the long pause. I've been
>> in absence for the past couple weeks.)
>>  1) the window.pageTiming attribute should be available for each browsing
>> context, not only the top-level one.
>>
>
> You need to use [Supplemental] before "interface Window" as you are not
> defining the Window interface in this draft, just an extension.
>
>
> The draft does not explain why the different navigation methods need to be
> distinguished. Assuming this feature can be justified I think it needs to be
> defined in more detail. E.g. what needs to be returned if a page is loaded
> inside a , , or  element? Is it useful that you do not
> get information about the entire redirect chain rather than just the one
> before you go to the current page?
>
> Is is important to share with the Web author whether the user opened the
> page in the current tab or a new one?
>

In the past we've found the type of navigation have much effect on the
loading latency of a page, e.g., forward/backward has more to do with
the browser itself than the apps provider's setup. So it is useful to be
able to distinguish these different cases.



>
>
> I also think it should be made more clear how exactly the specification
> works together with the navigate algorithm. It currently says "navigation
> event" where "navigation" is a pointer to the navigate algorithm in HTML5
> which does not define an event so it is unclear from where the timing should
> start.


>
> Why does this draft not contain the legacy timer APIs currently in HTML5?
>

Yes, one of my tasks right now is to make proper link-ups with other
html5 docs.


>
>
> (Maybe you should ask a Team contact for an account on dev.w3.org so it is
> easier for us to monitor changes. Would also be nice to have a single
> pointer for the draft.)
>

Yes, hopefully the next revision will be on dev.w3.org instead.

thanks,
Zhiheng


>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: RFC: WebApp timing

[Zhiheng Wang]

Hi, Michael,
   Good point indeed.

On Thu, Aug 13, 2009 at 12:49 AM, Michael Nordman wrote:

>
>> interface Window {
>
>
>>   readonly attribute Timing 
>>  
>> pageTiming;
>
>
>> };
>
> The pageTiming attribute represents the timing information related to the
>> current top-level browsing context. Each top-level browser context must have
>> a unique pageTiming attribute.
>
>
> You mention top-level browsing context specifically, not just browsing
> context.
>
> * Firstly, why not just 'browsing context'? Seems like these timings also
> apply to subframe navigations.
>

 Top level document is the main object we have been looking at. But as
you point out, the timing measures can also be applied to
subframes. (e.g., IE does have BeforeNavigate2 events for the root page and
each subframe.) And it's a good idea to accommodate
this case. I will see how I can make change accordingly.


>
> * Secondly, does that imply that accessing window.pageTiming from a nested
> frame returns the timing for its 'top' page? Or perhaps an 'empty' timing
> object or 'null'?
>

I think we can use a new navigation type, say, navigate_frame. This
could be useful in some cases, e.g., for a search result page to determine
if it has been "framed" by a third party page.

thanks,
Zhiheng

Re: RFC: WebApp timing

[Zhiheng Wang]

Hi, Gregg,

On Thu, Aug 13, 2009 at 12:07 AM, Gregg Tavares  wrote:

>
>
> On Wed, Aug 12, 2009 at 6:12 PM, Zhiheng Wang  wrote:
>
>> Hello,
>>
>>We recently started a draft to provide timing-related APIs in browsers.
>> The goal is to add the missing pieces in webapp latency measurements
>> using Javascript. As a starter, right now we've only include a
>> minimum set of interfaces we consider necessary, which mainly focuse on
>> the time and type of the
>> navigation.
>>
>>The first cut of the draft is attached below. It's sketchy but should
>> hold much of our ideas. We are
>> still actively working on it. Any interest and feedback on the draft are
>> highly welcome.
>>
>
> Is this a place that app specific timing would be useful to add or is that
> already covered somewhere else?
>
> In other words, I'm looking for an API that helps me do this
>
> var timer = new Timer();
> timer.start();
> for (var x = 0; x < 10; ++x) { }
> var elapsedTime = timer.elapsedTime;
> document.write("loop took " + elapsedTime + " seconds");
>
> Where elapsedTime is some relatively high precision number so this might
> print
>
> loop took 0.0145 seconds
>
> (using Date, which only has a precision of milliseconds, is not enough)
>

This is indeed something we have been debating: shall we require a high
res timer or not. To enable that, the value of the
property should be a floating number in either second or msec. We currently
opt for keeping it as int in msec to make it
slightly more consistent with the JS Date.getTime(). And, also, msec
resolution seems to be sufficient in terms of measuring
page loading latency.

   That said, if there is enough interest in pursuing a finer res timer, we
can definitely account for that.

thanks,
Zhiheng



>
>
>
>>
>> cheers,
>> Zhiheng
>>
>
>

Re: RFC: WebApp timing

[Zhiheng Wang]

Hi, Bil,

On Wed, Aug 12, 2009 at 11:13 PM, Bil Corry  wrote:

> Zhiheng Wang wrote on 8/12/2009 8:12 PM:
> >The first cut of the draft is attached below. It's sketchy but should
> > hold much of our ideas. We are
> > still actively working on it. Any interest and feedback on the draft are
> > highly welcome.
>
> For navigationType, how would bookmarks, XHR, iframes and "open link in a
> new window" be reported?


   bookmarks: navigation_other
   XHR: this tells the current document is likely a sub-document like a
frame. The current spec is limited to top-level window but it should be
   extended to frames as well. In that case, a new navigation type
like navigation_frame might be appropriate?
   "open link in a new window" should use navigation_new_window.
   Obviously the navigationType should be better discussed in the draft. I
will work on it. :)



>
>
> For navigationTime (and the other timers), it's a measure of the elapsed
> time from when the navigation is initiated until when?


 It measures the time between the Unix epoch and the time of the
navigation start, i.e., it answers "when the current document
is initiated by user/browser/redirect, etc.

thanks,
Zhiheng



>
>
>
> - Bil
>
>

RFC: WebApp timing

[Zhiheng Wang]

Hello,

   We recently started a draft to provide timing-related APIs in browsers.
The goal is to add the missingpieces in webapp latency measurements using
Javascript. As a starter, right now we've only include a
minimum set of interfaces we consider necessary, which mainly focuse on the
time and type of the
navigation.

   The first cut of the draft is attached below. It's sketchy but should
hold much of our ideas. We are
still actively working on it. Any interest and feedback on the draft are
highly welcome.

cheers,
Zhiheng
Title: Web Timing





Web Timing
Working Draft 12 August 2009

  This version: 
  http://example.com/ 
  Latest version: 
  http://example.com/ 
  Previous versions: 
  http://example.com/ 
  Editors: 
  Zhiheng Wang, Google 
  Inc., zhihe...@google.com 
Copyright 2009, All Rights Reserved
Abstract
This specification defines a set of APIs for web applications to access 
timing information. 
Status of this document
This is a work in progress and may change without any 
notices. 
If you wish to make comments regarding this document, please send them to 
zhihe...@google.com. All feedback is welcome. 
Table of Contents
Introduction
This section is non-normative
User latency is an importing quality benchmark for Web Applications. While 
_javascript_-based mechanisms can provide comprehensive instrumentations user 
latency measurements within an application, in many cases, they are not able to 
provide a complete end-to-end latency picture due to the missing latency pieces 
from the user agents. This document introduces a set of timing APIs aiming to 
provide the missing pieces. 
Conformance requirements
All diagrams, examples, and notes in this specification are non-normative, as 
are all sections explicitly marked non-normative. Everything else in this 
specification is normative. 
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are 
to be interpreted as described in RFC2119. For readability, these words do not 
appear in all uppercase letters in this specification. [RFC2119] 

Requirements phrased in the imperative as part of algorithms (such as "strip 
any leading space characters" or "return false and abort these steps") are to be 
interpreted with the meaning of the key word ("must", "should", "may", etc) used 
in introducing the algorithm. 
Some conformance requirements are phrased as requirements on attributes, 
methods or objects. Such requirements are to be interpreted as requirements on 
user agents. 
Conformance requirements phrased as algorithms or specific steps may be 
implemented in any manner, so long as the end result is equivalent. (In 
particular, the algorithms defined in this specification are intended to be easy 
to follow, and not intended to be performant.) 
Terminology
The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of the 
more accurate "an object implementing the interface Foo". 

The term DOM is used to refer to the API set made available to scripts in Web 
applications, and does not necessarily imply the existence of an actual 
Document object or of any other Node objects as 
defined in the DOM Core specifications. [DOM3CORE] 

A DOM attribute is said to be getting when its value is being 
retrieved (e.g. by author script), and is said to be setting when a new 
value is assigned to it. 
The term "_javascript_" is used to refer to ECMA262, rather than the official 
term ECMAScript, since the term _javascript_ is more widely known. [ECMA262] 

Web Application Timing
Introduction
This section is non-normative

This specification introduces a set of of browser interfaces that provide Web 
applications with timing-related information. This specification does not cover 
how Web applications leverage these interfaces to collect, store and report the 
provided information. 
The Timing 
interfaceinterface Timing {
  const unsigned short NAVIGATION_LINK = 0;
  const unsigned short NAVIGATION_REDIRECT_SERVER = 1;
  const unsigned short NAVIGATION_REDIRECT_META = 2;
  const unsigned short NAVIGATION_REDIRECT_ONLOAD = 3;
  const unsigned short NAVIGATION_REDIRECT_JAVASCRIPT = 4;
  const unsigned short NAVIGATION_FORWARD_BACK = 5;
  const unsigned short NAVIGATION_USER_BROWSER = 6;
  const unsigned short NAVIGATION_NEW_WINDOW = 7;
  const unsigned short NAVIGATION_RELOAD = 8;
  const unsigned short NAVIGATION_OTHER = 15;

  readonly attribute unsigned short navigationType;

  readonly attribute unsigned long navigationTime;

  readonly attribute unsigned long redirectionTime;

  readonly attribute unsigned long domainLookupTime;
};


The navigationType 
a

Window atttributes for timing info

[Zhiheng Wang]

Hello,
I am writing to seek interest of adding a set of window attributes in
the html5 specs
to let browser expose timing-related information of a page.

   Many web pages/apps these days use javascript to measure component/page
latencies. Some
open source project has also been trying to make it easier for web apps
authors to collect these
performance stats, one example is Jiffy (http://code.google.com/p/jiffy-web/)
presented in last year's
Velocity conference. All these apps will benefit if the browser can expose
some timing-related info
through some attributes of the window object. For example, window.[foo] to
give the elapse time
since the page transition.

I will be happy to draft the specs for comments if there is interest.

cheers,
Z