[minutes] 2012-05-16 Web Performance WG Teleconference #73

Meeting Summary:



1.       Media Timing / Improvements to Resource Timing

Mark Watson from Netflix presented two areas where he would have liked Resource Timing to be improved for audio, video, xhr elements: A) allow progress indication of a resource download and B) give the ability to identify different chunks of byte data for a particular resource. The working group felt that progress indication was out of scope of the Timing APIs, which are designed for post processing analysis rather than real time decision making, and may be better suited for the respective specs defining those media elements. As for the ability to identify different chunks of data, this was something we would like to address in the Resource Timing spec. It wasn't clear if the current spec behavior would treat media elements as a single resource or multiple chunks of data that would need to be tied to the initiating resource. The working group will analyze this second issue in our next week's call and the mailing list.



2.       Navigation Timing to Recommendation

Sigbjorn raised a concern on whether the working group should continue standardizing the Navigation Timing spec to Recommendation and work on the newer navigation interfaces in the Navigation Timing 2 spec, or to move the current Navigation Timing spec to a Note and only standardizing the new navigation interfaces. Considering the two interfaces are not incompatible with each other, two user agents have implemented an unprefixed implementation and one user agent a prefixed implementation, customers have taken dependencies on the API, most working group members felt we should standardize the Navigation Timing spec. The counter argument was if we want to recommend the new API to developers, we should not standardize Navigation Timing, as it would send mixed signals. The working group has decided to continue this discussion once Philippe is back from vacation, so we can also get his perspective. Most of the discussions have been on the mailing list on these threads: http://lists.w3.org/Archives/Public/public-web-perf/2012May/0107.html, http://lists.w3.org/Archives/Public/public-web-perf/2012May/0108.html.


Detailed Notes:



Web Perf Teleconference #72 5/16/2012



IRC log: http://www.w3.org/2012/05/16-webperf-irc



Meeting Minutes: http://www.w3.org/2012/05/16-webperf-minutes.html



Attendees

Present for Navigation Timing, Resource Timing and User Timing (4-5PM EST/1-2PM PST)

Jatinder Mann, Arvind Jain, Tony Gentilcore, Sigbjorn Vik, Mark Watson, Alois Reitbauer


Present for Page Visibility, Efficient Script Yielding, Display Paint Notifications (4-5PM EST/2-3PM PST)

Meeting cancelled.



Scribe

Jatinder Mann



Contents

Agenda

1. Media Timing (audio, video, embed) discussion

2. Navigation Timing test case resolution

3. Creating Navigation Timing 2 specification resolution

4. Resource Timing initiatorType discussion

5. Resource Timing startTime discussion

6. Page Visibility ISSUE-8 resolution



--------------------------------------------------------------------------------
Media Timing
Jatinder: We have Mark from Netflix here today to discuss audio and video requirements for a performance metric.
Mark: We wanted the JavaScript aspect to determine the throughput rate of video and audio elements, so we can make decisions and update the user experience. We saw what you have in Resource Timing and we noticed that it covers both the video element and XHRs. Two things I noticed were we use for adaptive streaming is byte range request, which in itself is a http request and we would like to see that data captured, and the progress of the request, so if
... the data arrives.
Arvind: One of the fundamental differences is today Resource Timing is made available once the entire resource has been downloaded. Seems like you are asking for a progress indicator.
Mark: Yes, I think that's a part of it.
Arvind: I think this would require a significant change to the Resource Timing spec. Let me understand the use case, as chucks of the video is getting downloaded, you will make a decision and change the bitrate. Can't you do this already using the media source API? You would make a XHR request and then you would see when it comes back...
... Do we support XHRs in Resource Timing?
Jatinder: Yes
Arvind: We should have a XHR for every AJAX call we would make? I would expect that it would. It would include the range request
Mark: It seems like the name attribute is the unique identifier. For XHRs, we would want the URL and byte range together as the name attribute?
... The range request would seem like the basic data that you need.
Karen: We haven't discussed partial responses. We may want to include that as well?
Mark: We may want to include the header data, but you may open a can of worms from a privacy point of view.
Arvind: With the resource timing, you will also see multiple resource timing objects for each chunk.
... Quite a few issues. Let's talk about them one at a time. The first is that for multiple ajax xhr calls, you will get multiple resource objects. We may want to include http headers into the resource timing. However, there were issues with that?
Tony: Yes, there could be privacy / fingerprinting issues with keeping that data around.
Karen: We should think about this in more detail before closing on it.
Arvind: Agree, let's chat more about this and close on it in the future.
Mark: If you had an event that would fire when each resource timing object was added, so you can determine which resource corresponds to which byte range. We can do this without giving the header information.
Alois: Is the goal really to determine the bandwidth so you can make decisions? Shouldn't we focus on how to get that data.
Mark: I would recommend providing JavaScript with as much information happening on the lower level network so it can make decisions. Seems like you have provided most of the low level information. One information missing seems like the byte arrival of data. You can imagine providing a property that would let you know how many bytes have arrived so far.
... I will have to go right now, however, I can join in another future call to discuss some more.
Tony: There's also one point that we should clarify is that this is after the fact analysis. It was never designed to provide real time progress data, UAs can add the data at anytime they wish, not real time.
Jatinder: I also agree that these APIs were designed for post processing analysis. Shouldn't the elements they are trying to download be extended to provide this type of progress data?
Arvind: We should talk about this more next week. Besides the progress issue, there is also the naming issues.
... The naming issue of XHRs seems like an immediate issue that we need to address in the Resource Timing.
... For things where we have multiple downloads for the same entity, the API already provides all the data, we should determine if we want to distinguish between them. Let's chat about them next week.
... Seems like we have two issues: progress indication and distinguishing between multiple chunks.
Sigbjorn: What would we do for a native video element?
Arvind: We should be give a single resource, I believe.
Jatinder: What about when the video isn't auto-playing? What about a seek?
... What does the dev tools do today?
Arvind: I believe its a single element (one line item) instead of multiple items.
Tony: I think we need to determine whether we should treat it as a single element or have multiple http requests.
Issue Determine how audio, video and embed elements appear in the timeline
Action Determine how audio, video and embed elements appear in the timeline
<trackbot> Sorry, couldn't find user - Determine
Action Jatinder Determine how audio, video and embed elements appear in the timeline
<trackbot> Created ACTION-104 - Determine how audio, video and embed elements appear in the timeline [on Jatinder Mann - due 2012-05-23].
Navigation Timing
Jatinder: As three browsers have implemented this API and two have them unprefixed, customers have started to use, and the API is useful and meets the goals it set out for, and UAs will not remove this API, we want to keep this spec to document the behavior and keep the test cases to ensure interoperability.
Tony: I do not want to pull out the current Navigation Timing, as vendors have unprefixed it and we want to continue to ensure the spec is standarized.
Arvind: In our last discussion, two weeks back, we agreed that the Navigation Timing 2 should state that Navigation Timing 1 should be implemented. If that is the case, we should standarize Navigation Timing.
Alois: As a developer, we would check the new API and the old API, so we would use both of them.
Arvind: If our goal is to have all browsers to implement the old API, then we should standarize the spec.
... We should get Philippe's opinion on this matter as well.
Jatinder: Considering Philippe will be back in a month and we aren't planning on moving the spec to PR until that point, we should close on this discussion at that point