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

Hi, Patrick,

   Pls find comments inline.

On Thu, Oct 7, 2010 at 2:22 PM, Patrick Meenan <pmeenan@webpagetest.org>wrote:

> Looks like you all had a great discussion.  I had a couple of quick
> questions (maybe spark discussion at your next meeting if the answers aren't
> clear and the diagram will probably help):
>
>
>
> In the case where there are redirects, does *fetchStart* come before the
> redirects or is it at the beginning of the actual base page?  If it doesn't
> include the redirects, is there a marker that consistently represents the
> "start of navigation" but doesn't include any times that are part of the
> previous document unload?
>

    If there is redirects, fetchStart comes at the beginning of the actual
base page. redirectStart will be the equivalent of navigationStart of the
first navigation
during the redirect. So, it does include the unload time of the previous
document.


>
>
> If there are multiple redirects chained together it looks like *
> redirectStart* and *redirectEnd* will encompass all of them, just wanted
> to verify that that was the case.
>

    Correct.



>
>
> In the case of *domainLookupStart*, *domainLookupEnd*, *connectStart* and
> *connectEnd* wouldn't it be more consistent to set them to zero if they
> did not occur?  That would be a lot more deterministic than snapping the
> times, otherwise a sub-ms operation may be indistinguishable from one that
> didn't happen.
>

   Ideally you are right. But based on some previous discussions, sometimes
it's difficult to tell if these operations
ever occur, which Anderson should be provide some more details if are
interested.

cheers,
Zhiheng



>
>
> Thanks,
>
>
>
> -Pat
>
>
>
> *From:* public-web-perf-request@w3.org [mailto:
> public-web-perf-request@w3.org] *On Behalf Of *Jason Weber
> *Sent:* Thursday, October 07, 2010 4:57 PM
> *To:* public-web-perf@w3.org
> *Cc:* Arvind Jain (arvind@google.com); Philippe Le Hegaret (plh@w3.org)
> *Subject:* Web Performance WG Meeting Notes (2010-10-05)
>
>
>
> *Web Performance Working Group Meeting Notes - October 5**th**, 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
> Arvind Jain, Google, arvind@google.com
> Zhiheng Wang, Google, zhihengw@google.com
> Tony Gentilcore, Google, tonyg@google.com
> Steve Souders, Google, steve@souders.org
> Jonas Sicking, Mozilla, jonas@sicking.cc
> Jason Weber, Microsoft, jweber@microsoft.com
> Anderson Quach, Microsoft, aquach@microsoft.com
> Seth McLaughlin, Microsoft, 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.
>
>
>
>