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

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 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.

 

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.

 

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 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
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.

 

Thanks, Arvind, Philippe, and Jason