[minutes] Web Performance WG Teleconference #108 2013-05-01

Meeting Summary:



1.     Spec to Recommendation

Page Visibility spec is expected to move to Recommendation next Thursday.



2.     Timing Specification Updates

The working group has simplified the Resource Timing onresourcebufferfull attribute to call the callback only once after the buffer is full for the first time, until the clearResourceTiming method is run again. Recording new entries in a temporary buffer while the callback is executing has been agreed to be a more complicated solution to just increasing the buffer size.

The working group is also investigating updating the following statement in the navigationStart definition of Navigation Timing Level 1: "If there is no previous document, this attribute must return the same value as fetchStart." The current definition doesn't include redirect time and all browser vendors appear to implement a different behavior where navigationStart < fetchStart.



3.     Resource Timing Test Cases

Microsoft completed reviewing the Intel and Google Resource Timing test cases and recommended approving 14 test cases. The other 8 test cases have potential bugs that have been shared with Intel and Google on the mailing list.



4.     Navigation Error Logging

Based on the working group discussion, Navigation Error Logging feature is disabled by default, requiring the developer to increase the buffer size to enable the feature.



As Navigation Error Logging only contains historical error data, it doesn't make sense to include the entries in the Performance Timeline view. As such, we're considering creating a new performance.getErrorEntries method for Navigation and Resource Error Logging. As Resource Error Logging will use DOMHighResTimeStamp, developers can impose Resource Errors on top of the Performance Timeline to see relatively when those errors occur.



The Error categories have been simplified to "dns", "tcp", "tls", and "http". If we need to add more errors, we can do so.



The onnavigationerrorbufferfull attribute is not necessary for Navigation Error Logging, because we don't expect this buffer to fill up as the first time JavaScript has an opportunity to run, you can upload all the errors.



We are still waiting on privacy reviews of this feature.



5.     TPAC Attendance

The working group would like to setup a face to face meeting at TPAC 2013.




W3C Web Performance WG Teleconference #108 2013-05-01



IRC log: http://www.w3.org/2013/05/01-webperf-irc



Meeting Minutes: http://www.w3.org/2013/05/01-webperf-minutes.html



Attendees

Jatinder Mann, Aaron Heady, Arvind Jain, James Simonsen, Philippe Le Hegaret


Scribe

Jatinder Mann



Agenda

1.     Discuss Timing spec feedback

2.     Discuss Timing test cases

3.     Discuss Error Logging specs

4.     Discuss Resource Priorities.

5.     Feedback on existing or new specifications

--------------------------------------------------------------------------------



Minutes:
Update on Existing Spec Status

Plh: Page Visibility should be published as a recommendation next Thursday.
... We expect that this will take push finalizing the charter by a bit.
Feedback on Timing specs

Jatinder: Let's discuss onresourcebufferfull callback simplifications.

Arvind: I've updated the spec based on feedback. The spec wasn't clear if the callback should be called every time another entry is added; I didnt think that was the intention, so I updated the spec. I also updated the N+1 and N buffer size issue for the callback.

Jatinder: I think we have consensus here.
... Arvind raised updating the definition of navigationStart in navigation timing when there is no previous document (new tab scenario). Can we get a test case that shows the redirect time? Looks like IE10 implements the spec; I want to understand this change first.

Arvind: Looks like in Chrome opening a new tab page and navigating to a page doesn't count as not having an unload. If you open the page by clicking open new tab, you should open a page with no unload.

Jatinder: Are we suggesting in that case where there isn't an unload, there is a redirect, navigationStart should be equal to redirectStart, otherwise fetchStart?

Arvind: That sounds right.
... What options do we have?

Plh: We can make the change in NT L2, or add an addendum to L1
Resource Timing Test Cases

Jatinder: I shared feedback on the Resource Timing test cases. I recommend approving 14 of the test cases as is. I wanted to discuss the others. The mail thread is here: http://lists.w3.org/Archives/Public/public-web-perf/2013May/0004.html
... http://w3c-test.org/webperf/tests/submission/Google/resource-timing/html/test_resource_cached.html
... This test case fetches 2 identical resources (with different query strings) to test if a 304 will create an entry. Looks like the test case expects a duplicate entry to be created, even though I would expect that we do not create a resource timing entry for the duplicate. Is this because the query string is different? Is Icon.png a different fetch from icon.png even if it's the same resource on the server?
... http://w3c-test.org/webperf/tests/submission/Google/resource-timing/html/test_resource_ignore_failures.html
... This test fetches a resource that doesn't exist (returns 404) and is expecting 0 resource timing entries. Looks like the test expects that the entry shouldn't be created. I wanted clarification if step 3.7 (if fetching the resource is aborted for any reason, abort the remaining step) means that we should not add this entry. Seems like it.

James: We should clarify that "aborted" includes HTTP errors.

plh: We should be consistent here between the two network requests.

James: With the 304, technically we are blocked waiting for the network response. The 404 you can never use it.

Jatinder: Let's follow up on these two on the list.
...

http://w3c-test.org/webperf/tests/submission/Intel/resource-timing/test_resource_timing_buffer_size_restriction.html.

This test cases creates 3 resources before ResourceTimingBufferSize is set to 2. Per spec text, "if the maxSize parameter is less than the number of elements currently stored in the buffer, no elements in the buffer are to be removed. The maxSize parameter will apply only after the clearResourceTimings method is called." The number of entries won't be truncated if they exist before a lesser buffer size is set

Jatinder: There are some onresourcebufferfull test cases that we should make sure are still accurate after the spec changes.

James: I'll follow up with Pan and fix these test cases.

Arvind: I wanted to discuss navigationStart in the Navigation Timing L2 spec.
... There is already a startTime equal to 0.0. navigationStart definition is redundant. I recommend we cut it.


Error Logging

Arvind: Seems like it is most appropriate if the initial buffer size was set to zero, and the developer could enable the feature by changing the buffer size.

Aaron: That seems reasonable.

Arvind: I don't think we should reuse Performance Timeline for Navigation Error Logging, as Performance Timeline defines startTime to be the start of the recorded event. Since this is historical, doesn't make sense.

Jatinder: We could specify a different performance.getErrorEntries that's different from performance.getEntries? Resource Errors could use getErrorEntries as well, but it would need to use DOMHighResTimeStamp.

Arvind: The errorType should also only be "dns", "tcp", "tls", "http".

Jatinder: Aaron, have you seen any errors outside of these?

Aaron: These are the only ones that come to mind.

<plh> </doctype>

Arvind: For Navigation Error Logging, I don't think we need to define an onnavigationerrorbufferfull, because the first time JavaScript runs, you can pull down all the details. The buffer should never be filled.

Aaron: Considering we talked about simplifying the callback for Resource Timing, this seems reasonable.

Jatinder: Okay, we should remove it.
TPAC Attendance

Arvind: Let's meet at TPAC this year.