[minutes] 20100929 Web Performance

Available at
http://www.w3.org/2010/09/29-webperf-minutes.html

Web Performance Working Group Teleconference
29 Sep 2010
See also: IRC log
http://www.w3.org/2010/09/29-webperf-irc


Attendees
Present
  SteveSouders, TonyG, Zhiheng, AndersonQuach, ArvindJain, JasonWeber
Regrets
  plh, NicJansma
Chair
  ArvindJain, JasonWeber
Scribe
  AndersonQuach
Contents

Topics
1. Feedback on the processing model.
2. Feedback on the lifetime management of the navigation timing, tied with the lifetime of the document object and interactivity with the unload event.
3. Resource Timing scenarios.
4. User Timings.
5. F2F meeting updates.
6. TPAC meeting updates.
7. Any other business.

Summary of Action Items

a.       Anderson to send feedback on the processing model to the discussion group

b.      Anderson to solicit feedback on the wording for the lifetime management of the navigation timing and navigation info interface.

c.       Anderson will create a draft of user timings for 10/1.

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


AndersonQuach: going thru the feedback in the web perf email list.
... That way the timeline in a cached DNS scenario would go from looking like this:
... (fs,dls,dle)---(cs)---(ce)

(fs)---(dls,dle,cs)---(ce)

AndersonQuach Let domainLookupStart, domainLookupEnd, be the same value as connectStart.

AndersonQuach Let connectStart, connectEnd be the same value as requestStart.

Zhiheng question, domainLookup, connectStart already init to fetchStart and have the same value, what's the scenario?

Zhiheng: how would we test if we were to snap to the latest timestamp?

AndersonQuach: good question.
... can be tested by breaking down case by case, i. dns cached, ii. connection established iii. doc cached.

Tony: the issue if we have time between phases in the event of these cached scenarios

Zhiheng: goal, network timing scenario, fine putting them into fetchStart, the variable in this case for dns and connection
... now the user agent will have wait for the timestamp to fill out the values.

AndersonQuach: so you're concerned with the implementation issue, difficultly?

Zhiheng: yes

Tony: dns lookup may be zero in the cache, the question is, in that case do we snap to the end or beginning of the time, either option seems fine. i don't understand why it's perferable to snap to the end.

AndersonQuach: would love to get feedback from other browser implemetnations.

Zhiheng: caching scenario may have different starting points, cache miss, request start the browser something to the network.
... always starting the requestStart when the browser does a cache lookup
... cache look up can come before the fetch

AndersonQuach: IE is abstracted from the networking request

Zhiheng: how about chrome
... can you differentiate lookup times from fetchign resource from cache or fetched the network

Tony: we could, we didn't want to for privacy reasons

Zhiheng: should we start from the look-up from cache or from when we fetch from the network, in the case of a cache miss. when should we start the requestStart timestamp

Tony: i believe in the current implementation, tell the http stack to get something, or it may hit the cache, or hit the network. we're timing the http stack api, get me a request. in that request time, we're including disk cache lookup

Zhiheng: we have some agreement

AndersonQuach: requestStart will have both the cache hit and cache miss time

Zhiheng: according to the html5 spec, fetchStart may come before requestStart

Tony: in chrome would be impossible for request to start before fetch

Zhiheng: instead of fetchStart we want to come up with another name, we are referring to the fetch process in html5

Tony: maybe, i'm not sure if our publicly facing names need to correspond.
... fetch start makes sense in our api

AndersonQuach: it would be okay to use fetch, as long as we are clear about its definition

Zhiheng: will look up and provide a reference

AndersonQuach: feedback, i think you meant the lifetime of the current document object and not the window object

Tony: I think it's tied to the window not the document.

Zhiheng: when you navigate across different documents, update timings. for a new document, a new window should be created.

Tony: I need to check on these.

<zhiheng> http://dev.w3.org/html5/spec/browsers.html#garbage-collection-and-browsing-contexts

Zhiheng: during the unload which navigation timing object should we provide, we should be reading the timing of the current browsing context

AndersonQuach: we agree that it should be tied to the current browsing context

Tony: HTML5 spec out pretty well, page cache in web kit and fast back in mozilla. when you do go back, fast back, you would get the navigation timing on the original load rather than generate a new one on a fast back. everything that was in the dom was restored back up. we'll need to cover this in the spec.
... search for page hide and page show events

AndersonQuach: ok
... provide feedback through email on the clarification on the language.

list the agenda

move to agendum 5

AndersonQuach: use the f2f to talk about best practices and test cases.

Zhiheng: list the goals for each items.

AndersonQuach: use the time to build out the list of goals and successes
... browser implementation neutral, compatible time phases
... use the meeting to also close on open issues

JasonWeber: also treat the spec, section by section and talking about it with everyone in the room and agree on the content of each section says. sign-off on the design and be confident when we publish this out. this will be aligned with the implementation with ie9 and chrome.

Zhiheng: sounds good

JasonWeber: that can take 1-2hrs on 10/5
... make it a priority, start with open issue, go with spec review phase, and then we close on that we can move to best practices and test cases and other areas. i'm very excited pulling off the vendor prefix, for the next ie platform preview.

Zhiheng: that would be awesome.

Tony: yeah definitely.

list agenda

ArvindJain: are we having the meeting there? Microsoft will be remotely attending

move to agendum 6

JasonWeber: Anderson and myself do not plan on attending, as we will meet face to face in mountainview

Zhiheng: i need to confirm with my management

JasonWeber: we plan on attending remotely, Microsoft will be largely represented at TPAC in other areas

ArvindJain: we'll get back to you on the attendence