W3C home > Mailing lists > Public > public-web-perf@w3.org > November 2010

Re: [NavigationTiming] a couple questions

From: Tony Gentilcore <tonyg@google.com>
Date: Wed, 10 Nov 2010 08:32:29 -0800
Message-ID: <AANLkTimimHCdJ6zF8mGbXocd8rPok+CoFVbex9bwhSyR@mail.gmail.com>
To: Sylvain Hellegouarch <sh@defuze.org>
Cc: Anne van Kesteren <annevk@opera.com>, Zhiheng Wang <zhihengw@google.com>, Jonas Sicking <jonas@sicking.cc>, public-web-perf <public-web-perf@w3.org>
We discussed naming/location on a previous call. IIRC, here were the
points we came to (others please keep me honest here):

- Hang it under console? The goal of the performance object is to
expose information to the DOM in production. This is distinct from
console which only interacts with the debugging console during
development.
- Hang it under document? There are subtle differences between window
and document lifetimes (for instance a late document.write can replace
the document). The performance information outlasts a document, so it
didn't make a whole lot of sense there. However, I don't recall any
strong objections to moving it if we want to revisit.
- Will global performance conflict with many sites? We discussed
allowing it to be replaceable so that if a site were to define var
performance or window.performance, it would override the built-in.
This would mitigate all but the most pathological conflicts.
Unfortunately, I don't recall where we ended up on this discussion and
can't find anything one way or the other in the spec.

Another alternative which I don't think we discussed would be to hang
them directly under navigator. e.g. navigator.timing,
navigator.navigation...

-Tony

On Wed, Nov 10, 2010 at 2:20 AM, Sylvain Hellegouarch <sh@defuze.org> wrote:
>
>
> On Wed, Nov 10, 2010 at 11:16 AM, Anne van Kesteren <annevk@opera.com>
> wrote:
>>
>> On Wed, 10 Nov 2010 07:11:25 +0100, Jonas Sicking <jonas@sicking.cc>
>> wrote:
>>>
>>> One solution would be to stick it on the document object. Another to
>>> come up with a more exotic name though I have to admit any good
>>> suggestions escape me at the moment.
>>
>> One idea I had was to put it on window.console if we are going to
>> standardize parts of window.console anyway since the performance API is
>> mostly for debugging and figuring out what is going on.
>>
>
>
> Most likely indeed. However, I was wondering if it would make sense to use
> the performance API as a monitoring platform in production as well. It could
> offer some interesting pieces of information. Mind you, I'm not familiar
> with its impact on the resource processing itself.
> --
> - Sylvain
> http://www.defuze.org
> http://twitter.com/lawouach
>
Received on Wednesday, 10 November 2010 16:33:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 December 2010 18:13:56 GMT