Re: [WebTiming] HTMLElement timing

    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.rachitsky@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 <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
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/-WebTiming--HTMLElement-timing-tp27335161p27427432.html
> Sent from the w3.org - public-webapps mailing list archive at Nabble.com.
>
>
>
>