[minutes] Web Performance WG Teleconference #109 2013-05-08

Meeting Summary:



1.     Timing Specification Updates

The Navigation Timing L1 spec definition of navigationStart for a previous definition has been updated to be: "If there is no previous document, this attribute must return the time the current document is created." We are working on adding this new definition to the 2nd edition of Navigation Timing L1 spec.



There were a few clarifications we may want to make in the Resource Timing spec. An example of a script dynamically updating an iframe src to point to another URL shouldn't include the initial about:blank iframe as an entry, as the about:blank wasn't a navigation. The other update is to see if the spec correctly covers the case for a 304 resource; in this case, as there was a network delay, this timing should be reported.



2.     Error Logging Specs

The Navigation Error Logging spec, https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html, has been updated. Please review and provide feedback.



The spec currently only specifies the general error categories. Dan has taken the task of putting together a list of specific error types that the spec should reference.



The spec currently defines a getNavigationErrors method. Seeing that there is interest in potentially expanding to other types of errors, we need to investigate if we can future proof this API now. Alternatively, since navigation errors are probably the only historical errors types we may want to store, we may want to leave this method as is, as this would be the only asynchronous API call. The working group will review and discuss further.



3.     Diagnostics

We will be reviewing additional diagnostics APIs in next week's conference call.




W3C Web Performance WG Teleconference #109 2013-05-08



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



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



Attendees

Arvind Jain, James Simonsen, Jatinder Mann, Daniel Austin, Alois Reitbauer


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:


Timing Spec Feedback

Jatinder: It looks like all browsers have implemented a somewhat different about:blank performance.timing attribute values. Seeing that these timing values aren't very useful to site developers, we can just specify that user agents MUST define the attributes, to avoid throwing an exception, but add a SHOULD clause on the expected values. Thoughts?

Arvind: The only change I made was that if there is no previous document, the attribute must return the time the current document is created.
... I think the spec is clear here as is.
... I asked Philippe to update the edition 2 of the navigation timing spec to include.

Jatinder: I thought we had added that about:blank example after an discussion on that example. What should we do in the case that one creates an about:blank iframe and changes the source value later? Should there be only one iframe entry or two?

Arvind: Technically, the about:blank document can't be fetched. There should only be one resource entry.
... I think we should update the example to state that the about:blank case shouldn't be included.

Jatinder: Test cases are assuming 304 should add an entry but 404 shouldn't add an entry. Seems like both of these are examples of when the body of the resource never came down. The processing model step 7 states: "If fetching the resource is aborted for any reason, abort the remaining steps."
... Should we include 304s?

Arvind: 304 does mean that there is some time spent in the networking layer, before the resource is pulled from the cache. Let me check to see if the processing model covers this as is.

Alois: We found that sometimes in Chrome resources that haven't been completed are added.
... It's useful to get that missing error data. Also the case if the resource is aborted, if the resource leaves the page midway.

Jatinder: There is value in putting the resource error data in the same timeline as resource timing.

Arvind: Having them in the same timeline means that you can see the attribute values for each of the successful phase, which is useful.

Jatinder: I rather we standarize Resource Timing L1 as is, and discuss whether we add aborted/error resources in Resource Error Loggin or Resource Timing Level 2.

Arvind: I like that idea as well.

<Alois> where is the latest version of nav error logging?

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html

Dan: We should make sure we include aborted/abandoned resources.
Navigation Error Logging

Arvind: I made some updates to the Navigation Error Logging specs: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html.

Dan: I don't like the idea of only giving the general categories, it may not be as useful.

Arvind: I don't think we should define the actual errors. We should link to a reference HTTP errors.

Dan: There are some errors that we need to actually define. I will put together a list and send it out for discussion.

Jatinder: What do we plan to do if we want to exclude a class of error types?

Dan: We can add a list of errors that we can exclude.

Arvind: I rather we let the User Agent just decide which errors to exclude.
... As there is a local storage read, I made the calls asynchronous.

Jatinder: I noticed that the method name is getNavigationErrors. Should we make it future proof by making a getErrors method?

Dan: There was a discussion in HTML about possibly expanding this interface for other errors.

Arvind: Can you send a link?

Dan: There are a number of options on how to future proof this API.

Jatinder: I like the idea of future proofing. At the same time, I think this will be the only historical data we store, so probably the only time we need an asynchronous call. Something to think about. Let's review the spec and give feedback on the mailing list.
Diagnostics

Jatinder: Since we are almost out of time, let's make sure to schedule Diagnostics discussion for next week's conference call.