Re: Resource Timing - What's included

> Our Resource Timing interface is scoped to simply be a DOM interface. 
> Even though we (as web developers) would be able to benefit from knowing 
> the cache status of our visitors -- there are many useful scenarios that 
> could enable -- we have to respect the user's privacy concerns.

I still don't understand why, as I've asked a number of times through 
various threads on this and similar discussions, we can't expose the more 
sensitive data only to script resources which originated from the same 
domain as the page, as opposed to third-party resources?



> I agree with your desire to have timing information for all resources, but 
> I don't think it's in the scope of what we're trying to achieve for 
> Resource Timing.  For Resource Timing, we are essentially trying to mimic 
> the information available from Network panels in developer tools.
> ...
> Including "timing" information for *all* resources (whatever that is 
> defined is) is a much larger, and more challenging issue.
> ...
> With your example of multiple IMG tags referring to the same resource, you 
> would be suggesting that all IMGs on the page would be included in the RT 
> array.  Additionally, SCRIPT elements (even inline ones) would be 
> included, because they block parsing progress.  Continuing down that line 
> of thought, TABLEs (large ones take a while to parse) and SVGs (even 
> inline) would be included, etc.  It becomes a much larger and more complex 
> spec at that point.

No, that's not what I'm suggesting at all. I'm not suggesting that any 
"large" DOM element be exposed in the timing array. I'm saying that any DOM 
element which refers to an external resource be included, even if that DOM 
element is referring to an resource that has already begun it's request by 
being asked for earlier in the DOM. So, all <img>, <object>, <script>, 
<link> and any other such elements, if they have a src/href attribute 
specified, should show up in the resource timing array, even if that means 
there are strictly duplicates listed in terms of the actual URL for the 
resources.

A subsequent <img> or <script> tag referring to a duplicate URL still 
affects the way the page is constructed/rendered, even if it's actual 
networking-layer effects are minimal or zero. We should be able to capture 
ALL information about external resources that affect the page. Any list of 
resources that is incomplete is a failure (IMHO) of this spec.


> Additionally, we are proposing only exposing new, previously unavailable 
> information to the user -- the network latencies.  The in-browser timing 
> delays you mention are all somewhat measurable today via JavaScript.

"somewhat measurable" is about as useful as "not measureable in any reliable 
way at all". JavaScript timers are horribly inaccurate with such 
sub-millisecond type actions, which is why it would be extremely useful for 
accurate timing to be exposed via this interface.


--Kyle

Received on Monday, 30 May 2011 15:37:59 UTC