[minutes] 20101208 Web Performance Working Group

Web Performance WG Teleconference #13 Agenda 2010-12-08
08 Dec 2010

See also: IRC log<http://www.w3.org/2010/12/08-webperf-irc>

Minutes

http://www.w3.org/2010/12/08-webperf-minutes.html


Attendees
Present
+1.415.829.aaaa, [Microsoft], +1.650.704.aabb, +1.650.214.aacc, Plh, NicJansma, Anderson, JasonSobel, TonyG, JamesSimonsen, Zhiheng
Regrets
ArvindJain, JasonWeber
Chair
AndersonQuach
Scribe
AndersonQuach
Contents

  *   Topics<http://www.w3.org/2010/12/08-webperf-minutes.html#agenda>
     *   Discuss moving Navigation Timing to Last Call.<http://www.w3.org/2010/12/08-webperf-minutes.html#item01>
     *   Review feedback on test cases.<http://www.w3.org/2010/12/08-webperf-minutes.html#item02>
     *   Discuss feedback on the four Resource Timing proposals.<http://www.w3.org/2010/12/08-webperf-minutes.html#item03>
     *   Summary<http://www.w3.org/2010/12/08-webperf-minutes.html#item04>

A. Pending any additional feedback, let’s consult with the co-chairs to motion towards Last Call with the Navigation Timing specification.

B. Anderson will close the loop with the decision made in the last conference call to continue to use window.performance;

C. As a working group we will continue to submit and review conformance tests. Tests should focus on clearly defined goals, scope, description, and pass / fail criteria.

D. Collectively let’s work to clearly articulate, How the interface will be used, Understand the technical requirements for each design approach and the technical feasibility. This will be done by measuring the projected amount of memory required to store Resource Timings and the CPU / memory costs of aggregating resource timings via the add-event design approach.

________________________________

<scribe> scribe: AndersonQuach

<plh> zakimm list conferences

list the agenda

<plh> http://www.w3.org/TR/2010/WD-navigation-timing-20101207/


<plh> we published a new draft yesterday btw
Discuss moving Navigation Timing to Last Call.

AndersonQuach: Get confirmation with folks on the email thread with the naming decision to stick with window.performance;

move to agenda 2.

move to agenda 2
Review feedback on test cases.

NicJansma: Test case looks great. As a group what granularity / scope should each test be?

TonyG: The existing test just tests the attribute is defined.

NicJansma: The test should be modular and broken down.

TonyG: I hear about breaking them down by functionality.
... I can see splitting out the case where there may be 100 attributes and 99 pass,1 was missing and the test case may fail. We should be careful about the scope of the test. I agree.

NicJansma: I will be submitting additional tests towards the end of the week.

Zhiheng: All the requirements should have a conformance test.

TonyG: Yep.
... Design pattern, attribute_a < attribute_b; Using broad timings to capture the timeline.
... Server, CGI or PHP introduce deterministic latencies.
... Agree we should not be comparing network traces that require client software.

AndersonQuach: Sounds like we have agreement that each test needs to have clear goals, scope, description, objectives and pass / fail criteria.

move to agenda 3
Discuss feedback on the four Resource Timing proposals.

AndersonQuach: The goals of: i. safety for end-user security / information disclosure attacks. ii. does not over burden the browser in terms of management iii. ease of use of the interface.

NicJansma: Concern with having to register handlers, will have to run script everytime something finished downloading to collect the Resource Timing.
... Concerned with running script too early in the page, which can impede some user agents from HTML parsing and parallel downloads especially intialized in the head.

TonyG: From Google we hear, we have this one XHR, or one image. We can't handle collecting the data from all resources on the page. We need a single piece of data.

JasonSobel: If our handler, pulls out timing data, aggregate and ship it back. What kind of impact will that have on rendering flow.

NicJansma: We have not done experiments with this yet. However, it should scale with the page. It would be good to understand the overhead with these events firing.
... If the goal is to add events to log them into a data structure, some developers may be building a custom event log, especially if they want an aggregate of data.

Zhiheng: I agree with use cases out there, that want all resource timings and some use cases that want specific timing. It can be difficult for some developers to register the handler ahead of time.

NicJansma: We looked at the theoretical overhead of collecting all the resource timings. The average use case, would be reasonable to maintain in IE.

Zhiheng: We looked at external resources on the page and the memory usage, Anderson and Nic found this to be relatively small compared to the browser.

JamesSimonsen: With resource timing, we talk about resources are downloaded, when the user first sees a key element. We should think more long term, keeping track of things were first layed out on the screen. Developers want targeted resource timings.

JasonSobel: How does this apply to CSS and JavaScript?

JamesSimonsen: It does not, we need to design to extend to this type of functionality when an image was displayed on the screen. This can be part of a new future interface.

NicJansma: This is a separate thing outside of the current Resource Timing charter.

JamesSimonsen: Agreed. This can be a separate thing that relates to user visible timings.

AndersonQuach: The high-level scenarios are: i. aggregate collection of resource timings on the page ii. specific discrete access to the resource timings.

JasonSobel: What are the design constraints? Like memory usage and CPU usage.
... The design proposal, a. add event proposal and b. event log seem reasonable.

NicJansma: DOM proposal can lose data, if you change the URL of an element. Let's focus on the key proposals we care about.

TonyG: I'm okay with focusing on these two proposals, the add event and event log.

NicJansma: Will you be able to look at the trade-offs with respect to webkit with the two proposals?

TonyG: Ya we can look at it.

NicJansma: When we looked at the initial numbers it looked reasonable.
... The memory analysis is good to look at for the event log. What experiments should we look at for add event.

TonyG: Certainly, we could look at a complex site like cnn and see what the CPU / memory trade-offs with the add-event proposal.
... In the event log proposal, what other accessors are necessary for filtering the items for the event log.

AndersonQuach: Should be captured in the spec.

TonyG: How the API fits in with the rest of DOM API? The ways of accessing the resource timings? And the requirements for addressing the scenarios and technical feasibility. Concerned with re-creating with accessor of the DOM.

NicJansma: Good feedback.

Zhiheng: There is a benefit to be able to provide a way to access timings after the page is loaded.

rrsagent set logs world-visible
Summary

A. Pending any additional feedback, let’s consult with the co-chairs to motion towards Last Call with the Navigation Timing specification.

B. Anderson will close the loop with the decision made in the last conference call to continue to use window.performance;

C. As a working group we will continue to submit and review conformance tests. Tests should focus on clearly defined goals, scope, description, and pass / fail criteria.

D. Collectively let’s work to clearly articulate, How the interface will be used, Understand the technical requirements for each design approach and the technical feasibility. This will be done by measuring the projected amount of memory required to store Resource Timings and the CPU / memory costs of aggregating resource timings via the add-event design approach.