Re: Resource Timing - What's included

In principle, I don't disagree with this approach. However, I think the more important issue is which elements are in the array. The original design of this array is that only one entry per unique resource-URL would show up, and my contention all along is that every single container (which references an external resource) should have an entry in the array, even if that means duplicates.

In your model, that would reduce the amount of "waste" of empty 0's for network timing, because there wouldn't be properties automatically exposed, but instead each element's specific type of info could be queried on-demand.

So, are you agreeing that all containers (even duplicates) will appear in the array? If so, I agree with your idea. If not, I think there's still a fundamental "miss" in terms of the use-case I'm trying to address.


--Kyle




From: James Simonsen 
Sent: Thursday, June 09, 2011 4:43 PM
To: Kyle Simpson 
Cc: public-web-perf 
Subject: Re: Resource Timing - What's included


On Fri, Jun 3, 2011 at 8:18 AM, Kyle Simpson <getify@gmail.com> wrote:

  In the future, I think that same array of resources could potentially have new attributes added to each entry, such as their rendering timings (startRender, endRender, etc). But I'm not asking for that now. I am only asking that they be included in the array, as foundation for future improvements.



I fully agree that we need to have a foundation for exposing further information, but I'd like to do it in a slightly different way.


I'm worried that trying to put all possible information about an element in one place will lead to a lot of empty or unused information. For example, script parsing time is relevant to inline scripts, but network timing is not. So all those fields would be empty, but taking up space. Likewise, I don't expect every developer to care about every bit of information on a resource.


Instead, I'd like to solve the problem using composition. I would have one API (Unified Timing) that can access different aspects about the element. In my proposal, you could query PERF_SCRIPT to get an object containing parsing time and PERF_RESOURCE to get an object containing network information. The browser will only provide the ones that are populated. Developers would be free to pick and choose which of those are relevant to them.


James