RE: [NavigationTiming] a couple questions

With regards to the question: Will the global performance conflict with many sites -- in my initial investigation, I found that this would impact less than 0.00993% of thousands of high traffic Internet websites.
The most common pattern is the a global declaration of the name performance and subsequent setter + getter calling patterns:
var performance = 1; or var performance = {}; or var performance = '';

Given the low risk to Internet site compatibility, I recommend that we continue to use window.performance and the interface should remain read-only. 

Anderson Quach
IE Program Manager

-----Original Message-----
From: [] On Behalf Of Jonas Sicking
Sent: Wednesday, November 10, 2010 8:59 AM
To: Tony Gentilcore
Cc: Sylvain Hellegouarch; Anne van Kesteren; Zhiheng Wang; public-web-perf
Subject: Re: [NavigationTiming] a couple questions

On Wed, Nov 10, 2010 at 8:32 AM, Tony Gentilcore <> wrote:
> 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.

The console object is available to DOMs in production too.

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

document.write doesn't replace the document, it just replaces the contents (elements, textnodes, etc) of it.

> - Will global performance conflict with many sites?

Your guess is as good as mine. There's a lot of sites out there though, chances are good that many use variables with such a name.

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

Most, but not code that tests if a variable is there, or checks if it's true/false. I.e. code like

if (!performance) {
  performance = calculatePerfMetrics();

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

The navigator object is tricky since its lifetime is actually longer than that of the page. It survives from one page to the next within the same origin at least in gecko.

/ Jonas

Received on Tuesday, 16 November 2010 23:31:34 UTC