(as of Apr 30)
First, it says that "timing attributes are not skewed by adjustments to the system clock during the navigation." We might not be navigating when resources load, but they should still use a monotonic clock referenced from the initial page load so that we can construct an accurate timeline.
Also, what do we do about resources that load from iframes? Are they referenced from the iframe's navigation or from the root navigation? The latter seems most useful from my perspective, but maybe there are other concerns there.
"The startTime attribute must return..."Why doesn't this just return fetchStart? I'd like the range [startTime, startTime + duration] to encompass all of the values in the struct (except for the zeroed out ones). As it is now, fetchStart may occur before startTime.
"The duration attribute must return a timestamp equal to the difference between responseEnd and startTime, respectively."This can be simplified to: "The duration attribute must return the difference between responseEnd and startTime."
[...]
INITIATOR_AUDIO INITIATOR_VIDEO These ones are a little tricky to time. They don't necessarily load like other resources. Sometimes they're never-ending streams. Sometimes they're only partially loaded (user skips ahead). And sometimes they're only loaded lazily when the user hits play. I could imagine a situation where we had to open multiple connections too, which would make some of the timing attributes ambiguous. What are we supposed to do in these cases? It's possible that Resource Timing isn't sufficient for describing these elements. Maybe they should have they're own class of entries on the Performance Timeline. INITIATOR_SVG This one says it's used if "the initiator is the <svg> element, but there's no way for the <svg> element to load something. Should this instead read "elements in the SVG namespace?" That would pick up SVG's <script> or <font-face-uri> for instance.
Does the current spec state that when the document is loaded from www.mydomain.com<http://www.mydomain.com> that I will not get any timing information from www.yourdomain.com<http://www.yourdomain.com> ? This would make it impossible to monitor third party resources.
We've discussed the differences between ResourceTiming's startTime<http://www.w3c-test.org/webperf/specs/ResourceTiming/#performance-resource-timing> and fetchStart<http://www.w3c-test.org/webperf/specs/ResourceTiming/#fetch-start> before, but I think there is still a bit of confusion. Ignoring redirects for a moment, startTime is currently defined as "The startTime attribute must return the time immediately before the user agent starts to queue the resource for fetching". In a recent discussion with James [1], we talked about startTime always equaling fetchStart for non-redirection scenarios. However, we had also previously talked about startTime possibly being earlier than fetchStart, in the case that the browser queued a resource for download but does not immediately attempt to fetch it because of connection limits. For example, if you included 100 <img>s all on the same domain, the resources may all have a similar startTime (parsing HTML is fast), but their fetchStarts would differ on the later <img>s as connections became available. I believe the wording of startTime in the spec currently supports this notion, but I wanted to make sure everyone agreed that was the intention?
can we rename INITIATOR_IMAGE<http://www.w3c-test.org/webperf/specs/ResourceTiming/#sec-window.performance-attribute> to INITIATOR _IMG? All of the other initiator names use the HTML element name or concept, and IMAGE seems a bit ambiguous when it really only means the <IMG> tag.
The most popular initiator<http://www.w3c-test.org/webperf/specs/ResourceTiming/#sec-window.performance-attribute> that I see on the web that currently falls under INITIATOR_OTHER is input[type='image']. The second most popular is body[background='...']. We could add INITIATOR_INPUT and INITIATOR_BODY, though I don't feel strongly that we need them.
"The|startTime|attribute must return the time immediately before the user agent starts to queue the resource for fetching"
I think it would help clarify the spec if the queue was defined a little clearer. In the case where there is a long queue of resources to be fetched from a given fqdn (say, 100 images and 6 parallel connections per fqdn), is this the point at which it enters the backlog queue or is this the point at which it exits the backlog and gets scheduled on an actual socket?
If it is the point at which it enters the backlog queue can we add a block at the front of the diagram that includes the "blocked" time? If it is the time when it gets scheduled on a connection can we indicate that it will always equal either the redirectStart or fetchStart time?
clearResourceTimings - no exceptions if called with arguments?
setResourceTimingBufferSize - no exceptions if called with no arguments, a double or a string?
Does this mean we are missing test cases for this as well? Calling setResourceTimingBufferSize with a variable that with some goodwill can be parsed as an integer is an area ripe for incompatibilities unless specified. We really need both TCs and a specification on this before moving further.
[various edits]
What's the status of the thinking on Opt out vs Opt in default?In the latest editor's draft of the spec The initiatorType attribute has changed from an integer to a string, can anyone explain the thinking behind this (it's more for my curiosity, but I see the attribute in PerformanceNavigation spec are integers)
[Misc clarifications]