Web Performance WG Meeting Notes (2010-10-05)

Web Performance Working Group Meeting Notes - October 5th, 2010

Location
Host: Google Inc.
Time/Duration: 12:00-5:00pm
Address: 2000 Charleston Rd, Mountain View, CA 94043


Agenda
12:00     Meet and greet in lobby, drop bags in conference room
1:00        Review NavigationTiming Specification
-       Walk through entire document together.
-       Discuss open issues inline.
-       Resolving issues where possible.
-       Discuss where Chrome and IE implementations stray from document.
3:00        Discuss next steps for NavigationTiming specification
-       Removing namespaces from webkit and IE
-       Schedule to move to recommendation.
3:30        Discuss conformance testing for NavigationTiming
-       Types of test cases.
-       Schedule for test case creation.
4:00        ResourceTiming & UserTiming Discussion
5:00        Special Interest Group Interest


Attendees
Philippe Le Hegaret, W3C, plh@w3.org<mailto:plh@w3.org>
Arvind Jain, Google, arvind@google.com<mailto:arvind@google.com>
Zhiheng Wang, Google, zhihengw@google.com<mailto:zhihengw@google.com>
Tony Gentilcore, Google, tonyg@google.com<mailto:tonyg@google.com>
Steve Souders, Google, steve@souders.org<mailto:steve@souders.org>
Jonas Sicking, Mozilla, jonas@sicking.cc<mailto:jonas@sicking.cc>
Jason Weber, Microsoft, jweber@microsoft.com<mailto:jweber@microsoft.com>
Anderson Quach, Microsoft, aquach@microsoft.com<mailto:aquach@microsoft.com>
Seth McLaughlin, Microsoft, Seth.McLaughlin@microsoft.com<mailto:Seth.McLaughlin@microsoft.com>

Discussion Notes
Introduction Section: The example says it measures the elapsed time from when the user clicks a link which isn't accurate. We should be clearer about what the sample measures.

Diagram: We spent a lot of time diagraming timelines and stages. We need to add a diagram to the specification before next week to help guide the conversation.

There was a productive conversation around the goals and these were listed on the board (we didn't discuss relative priorities of these):
*       Provide useful and actionable data for developers to make sites faster.
*       Keep the end-user safe and not leak information about their browsing history.
*       Capture the perceived timing as observed by the end-user in a navigation.

Privacy: We spent over an hour discussing the privacy implications of sharing a pages onunload duration and potential redirections with the page that's being navigated to. This is a difficult problem with no easy answer. On one hand, it's important for sites to understand the actual experience their customers are facing. On the other hand, this could be considered customer information and it's not something that's within the developer's control. We debated the actual sensitivity of the information. Browsers today already share the referring domain name. Is privacy compromised further by also sharing how long it took to unload that domain and redirect the user? There were different opinions on this topic but we agreed that protecting user privacy is an important aspect of the design. We also discussed different solutions that allow developers to measure the onunload and redirection when navigating within their site where they do have control. We agreed to go with a single origin policy for the moment, nulling out values when the navigation occurs cross origin, and then investigate this further with our respective privacy and security experts. We also need to specifically look at the naviationStart attribute to understand if this needs to fall under the same origin policy (assuming we stay with the same origin policy). This was the single largest outstanding issue from the day.

navigationStart Attribute
-       Do we have the right name? If felt like we needed a more descriptive marker name to denote the user committing the navigation instead of the use of navigation start.
-       We need to more crisply define this as the time when the browser first starts to load the webpage. This is as close to the user action (e.g. click) as possible. Should we call this user action?
-       Is this only available under the same origin policy or should a domain know how long it took the browser to get from navigationStart (user action) to fetch start.

unloadEventStart Attribute
-       Subject to same origin policy. Will only be populated on the same origin as the root document, the user committed navigation has the same origin as the target document.

unloadEventEnd Attribute
-       There was good discussion around how the unload event does not synchronously occur before the navigation start occurs. Firefox has the FastBack cache and Chrome/IE use similar techniques to service the network request as quickly as possible.
-       Should also be zero if the unloadEventEnd is not done.
-       Subject to same origin policy.

redirectStart Attribute
-       Need to rephrase to be clearer, this is when the browser started the request that turned out to be the redirect.
-       Subject to same origin policy.

redirectEnd Attribute
-       Subject to same origin policy.

fetchStart Attribute
-       General Agreement around how this behaves.
-       Agreement that it's okay to diverge from the HTML5 definition of "fetch" which is something different. As long as it is clear about the begin of when the user agent fetches the root document.

domainLookupStart Attribute
-       Rather than saying "HTML file", rephrase to files on disk or comparable.
-       Clarify that this should be set to fetchStart value when domain lookup is not needed (e.g cached document, app cache or opening a local doc.)
-       General Agreement around how this behaves.

domainLookupEnd Attribute
-       Clarify that this should be set to fetchStart value when domain lookup is not needed (e.g cached document, app cache or opening a local doc.)
-       General Agreement around how this behaves.

connectStart and connectEnd Attributes
-       We need to provide better guidance around the specific conditions. Specifically, we need to be more specific about the scenarios where the browser reuses a connection. In these scenarios the value needs to snap to domainLookupEnd, which could have already snapped to fetchStart.

requestStart Attribute
-       General Agreement around how this behaves.

requestEnd Attribute
-       We agreed to remove this attribute since it directly maps to response start and is redundant.

responseEnd Attribute
-       Add support for scenario where connection is closed.
-       General Agreement around how this behaves.

domLoading Attribute
-       Agreement that the DOM event order and behavior needs to align with HTML5 spec.
-       Clarify that this is the time of the first occurrence of this event.
-       General Agreement around how this behaves.

domInteractive Attribute
-       Agreement that the DOM event order and behavior needs to align with HTML5 spec.
-       Clarify that this is the time of the first occurrence of this event.
-       General Agreement around how this behaves.

domContentLoaded Attribute
-       Agreement that the DOM event order and behavior needs to align with HTML5 spec.
-       Clarify that this is the time of the first occurrence of this event.
-       Should this be paired with Start/Stop events? Should there be both domContentLoadedStart and domContentLoadedStop events?
-       General Agreement around how this behaves.

domComplete Attribute
-       Agreement that the DOM event order and behavior needs to align with HTML5 spec.
-       General Agreement around how this behaves.

loadEventEndStart Attribute
-       Need more discussion, ran out of time.

loadEventEndStop Attribute
-       loadEventEnd must also include when the load event is not yet done.

NavigationInfo Interface
-       There was lots of discussion around whether this is relevant to the developer. The group appeared to lean toward removing this interface altogether but we need to continue the conversation.
-       If we keep this interface, there appeared to be consensus that we should remove the new window type.

Section 4.5 - Processing Model
-       We didn't have time to go through the processing model in depth. This will be one of more important topics for the weekly meeting and the conversation should be aided by having the diagram. A couple of things that were touched on are below:
-       The lifetime of the timing object of the Navigation Timing interface should be of the current browser context.
-       Step four should reference the unload event starting and ending, not the unloading of the previous document.
-       Step 14 should be consistent with the definitions in section 4.2.
-       Step 20 should refer to section 8.2.6 The End in the HTML5 spec.


Timeline for Navigation Timings
10/08/2010: Update Navigation Timing spec based on face-to-face meeting.
10/13/2010: Review changes and work towards a published draft.
10/29/2010: Last Call
01/07/2011: Candidate Review
03/01/2011: Proposed Recommendation


Action Items
Zhigang: Add diagram showing timeline in spec.
Zhigang: Update Navigation Timing spec based on feedback listed above.
Microsoft/Google/Mozilla: Investigate privacy implications around cross origin unload information.



Please let us know if you have any questions.

Thanks, Arvind, Philippe, and Jason