TPAC 2011 Web Performance WG 2011-11-01 from Jatinder Mann on 2011-11-09 (public-web-perf@w3.org from November 2011)

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 9 Nov 2011 00:38:50 +0000
To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B040A86275A@TK5EX14MBXC252.redmond.corp.microsoft.>

TPAC 2011 Web Performance WG
November 1, 2011 1-5PM (PST), Santa Clara, CA

1. Attendees
Alois Reitbauer (DynaTrace), Arvind Jain (Google), Zhiheng Wang (Google), James Simenson (Google), Ganesh Rao (Intel), Jatinder Mann (Microsoft), Jason Weber (Microsoft), Cameron McCormack (Mozilla), Philippe Le Hegaret (W3C), LG, Samsung

2. Agenda

1:00pm - 1:30pm - Operational Discussion.

1:30pm - 2:30pm - Navigation Timing to Recommended.

2:30pm - 2:45pm - Break

2:45pm - 3:45pm - RequestAnimationFrame Open Issues.

3:45pm - 5:00pm - New Performance Investments for this Working Group.

3. Summary
The following action items have been identified:

Weekly Conference Call

* Due to geographic diversity of the working group members, the current 1PM-3PM PST time slot for both portions of the conference call is not working well for some members. We would like to propose moving the Timing spec (first half) portion of the call to 10AM PST and the second half to remain at 2PM PST. Unless there are any objections, we will like to make this change for next week's meeting.

Navigation Timing

* window.performance object test case

Per our review of the Navigation Timing test cases, we appear to not test the existence of the window.performance object. Zhiheng will submit a test case for this missing scenario within a week. ACTION 56: Add Object test case for Navigation Timing - http://www.w3.org/2010/webperf/track/actions/56 .

* Firefox failed test cases

Per mailing list conversations, the latest Firefox dev branch build appears to be failing on a few of the Navigation Timing test cases, http://w3c-test.org/webperf/tests/#navigation_timing. As we have verified the accuracy of the test cases, Zhiheng will take an action item to open Bugzilla bugs on Firefox where Firefox fails Navigation Timing tests. ACTION 57: Create Bugzilla bugs on Navigation Timing test cases that Firefox fails on - http://www.w3.org/2010/webperf/track/actions/57.

* Navigation Timing References

In order to ensure that all references to other specifications made in Navigation Timing are stable, we will update the definition of origin to point to the more stable Web Origin Concept specification and write a test case to test the document.readyState HTML5 reference. The following two action items are on Zhiheng: ACTION 67: Update the origin reference in Navigation Timing to point to The Web Origin Concept specification - http://www.w3.org/2010/webperf/track/actions/67 and ACTION 68: Write document.readyState test case to check impact to Navigation Timing - http://www.w3.org/2010/webperf/track/actions/68.

* Navigation Timing to Proposed Recommendation

Considering each feature in this specification has been implemented by a user agent and specification exit criteria of a full test suite and no remaining open issues has been met once the above open items are closed, the working group wants to move this specification to Proposed Recommendation this month. ACTION 58: Move Navigation Timing to PR - http://www.w3.org/2010/webperf/track/actions/58.

Resource Timing

* Remove string constants

The working group feels that specifications should only use grammar that is defined in the WebIDL specification. Per discussion with Cameron, his guidance is to not use string constants as there is a strong indication that string constants may be removed from the WebIDL specification going forward. Jatinder will take an action to no longer define string constants in all Timing and Page Visibility specifications and instead define valid string arguments. ACTION 59: Do not define string constants - http://www.w3.org/2010/webperf/track/actions/59.

* Resource Timing to Candidate Recommendation

Considering the working group believes this specification is stable and upon completion of the one action item identified today, all issues raised against this specification will have been formally addressed, the working group will like to move this specification to Candidate Recommendation and will like to be begin the Call for Implementations process. Philippe will take an action item to see that this specification is moved to CR this month. ACTION 60: Move Resource Timing to CR - http://www.w3.org/2010/webperf/track/actions/60.

User Timing

* Remove string constants

Per ACTION 58: Do not define string constants, all string constants in this spec will be removed.

* Abstract and Use Cases need clarification

Based on feedback, the abstract and use cases need to make it clear that this feature is to be used for high precision timing of script. Jatinder will take the action to update these sections to make them clear. ACTION 61: Update the User Timing abstract and use cases to be clear - http://www.w3.org/2010/webperf/track/actions/61.

* User Timing to Candidate Recommendation

Considering the working group believes this specification is stable and upon completion of the two action items identified today, all issues raised against this specification will have been formally addressed, the working group will like to move this specification to Candidate Recommendation and will like to be begin the Call for Implementations process. Philippe will take an action item to see that this specification is moved to CR this month. ACTION 62: Move User Timing to CR - http://www.w3.org/2010/webperf/track/actions/62.

Performance Timeline

* Remove string constants

Per ACTION 58: Do not define string constants, all string constants in this spec will be removed.

* Inherited objects should return sub-millisecond resolution

The spec isn't clear that inherited objects, like those returned from the getEntries method, should also return timestamps in sub-millisecond resolution (double). Jatinder will take an action item to update the spec. ACTION 63: Inherited objects should return sub-millisecond resolution - http://www.w3.org/2010/webperf/track/actions/63

* Abstract and Use Cases need clarification

Based on feedback, the abstract and use cases for this specification need to be more clear on this specs relationship with the other Timing specs. In particular, the abstract should clarify that this spec provides a consistent timing model. Jatinder will take the action to update this spec. ACTION 64: Update the Performance Timeline abstract and use cases to be clear - http://www.w3.org/2010/webperf/track/actions/64.

* Performance Timeline to Candidate Recommendation

Considering the working group believes this specification is stable and upon completion of the three action items identified today, all issues raised against this specification will have been formally addressed, the working group will like to move this specification to Candidate Recommendation and will like to be begin the Call for Implementations process. Philippe will take an action item to see that this specification is moved to CR this month. ACTION 65: Move Performance Timeline to CR - http://www.w3.org/2010/webperf/track/actions/65.

Page Visibility

* Remove string constants

Per ACTION 58: Do not define string constants, all string constants in this spec will be removed. Further, any string constants test cases will be removed from the test suite.

* Performance Timeline to Candidate Recommendation

Considering the working group believes this specification is stable and upon completion of the one action item identified today, all issues raised against this specification will have been formally addressed, the working group will like to move this specification to Candidate Recommendation. Philippe will take an action item to see that this specification is moved to CR this month. ACTION 66: Move Page Visibility to CR - http://www.w3.org/2010/webperf/track/actions/66. Further, as there are two interoperable implementations of this specification, the working group will like to take this specification to Proposed Recommendation by December 2011.

Timing control for script-based animations

* Closing remaining open issues

The working group reviewed and provided feedback on the ISSUE-2, ISSUE-3, and ISSUE-4, summarized in Section 6: requestAnimationFrame open issues section below. The working group would like the editors to make the appropriate spec updates this month. If the editors need help making these changes due to other time commitments, Jatinder can help make changes.

* Timing control to Last Call

Considering all issues raised against this specification have relative consensus in the working group, upon completion of the updates, the working group will like to take this specification to the Last Call stage by December 2011.

Potential New Specifications

* High Resolution Time

Jatinder will send proposed text for a high resolution time specification; ACTION 69: Create High Resolution Time specification - http://www.w3.org/2010/webperf/track/actions/69. This specification will define a monotonically increasing, high resolution time that can be used in the Timing specifications, requestAnimationFrame spec and any other specifications requiring higher resolution time.

* Background Activity

Jatinder will send proposed text for a background activity specification; ACTION 70: Share proposed Background Activity specification - http://www.w3.org/2010/webperf/track/actions/70. This specification will attempt to provide a consistent way for browsers to automatically throttle background activity to preserve battery life.

* More Instrumentation / Timing APIs

Alois will propose use cases for a instrumentation/timing API for tools to build web developer experiences on to the mailing list for further discussion. ACTION 71: Propose use cases for an Instrumentation/Timing API to be used for tooling purposes - http://www.w3.org/2010/webperf/track/actions/71.

* Memory Leaking and CPU Data APIs

Arvind will propose use cases for an API that will help web developers identify memory leaks and inefficient patterns in their code to the mailing list for further discussion. ACTION 72: Propose use cases for a Memory Leaking and CPU Data API - http://www.w3.org/2010/webperf/track/actions/72.

* Sending data back prior to an unload

Currently, analytics libraries typically spin for 500ms prior to the unload event to send data back to servers. Jason will follow up on more power efficient ways to send data back prior to the unload event and respond to the mailing list with ideas for further discussion. ACTION 73: Propose ideas on improving sending data prior to unload - http://www.w3.org/2010/webperf/track/actions/73.

Summary of Action Items:

* Alois

o ACTION 71: Propose use cases for an Instrumentation/Timing API to be used for tooling purposes.

* Arvind

o ACTION 72: Propose use cases for a Memory Leaking and CPU Data API.

* Cameron/James

o Make spec updates to close on ISSUE-2, ISSUE-3 and ISSUE-4.

* Jason

o ACTION 73: Propose ideas on improving sending data prior to unload.

* Jatinder

o ACTION 59: Do not define string constants.

o ACTION 61: Update the User Timing abstract and use cases to be clear.

o ACTION 63: Inherited objects should return sub-millisecond resolution.

o ACTION 64: Update the Performance Timeline abstract and use cases to be clear.

o ACTION 69: Create High Resolution Time specification.

o ACTION 70: Share proposed Background Activity specification.

* Philippe

o ACTION 58: Move Navigation Timing to PR.

o ACTION 60: Move Resource Timing to CR.

o ACTION 62: Move User Timing to CR.

o ACTION 65: Move Performance Timeline to CR.

o ACTION 66: Move Page Visibility to CR.

o Take Timing control specification to Last Call as soon as ISSUE-2, ISSUE-3 and ISSUE-4 are closed.

o Investigate what action needs to be taken to prove WebIDL references are stable.

* Zhiheng

o ACTION 56: Add Object test case for Navigation Timing.

o ACTION 57: Create Bugzilla bugs on Navigation Timing test cases that Firefox fails on.

o ACTION 67: Update the origin reference in Navigation Timing to point to The Web Origin Concept specification.

o ACTION 68: Write document.readyState test case to check impact to Navigation Timing

4. Operational Discussion
According to the Web Performance WG charter, http://www.w3.org/2011/04/webperf, as decided on April 2011, we had the following milestone timetable (Timetable_4_2011.png). This timetable is relatively out of date.

[cid:image001.png@01CC9E30.E89AA710]

Based on the W3C process, http://www.w3.org/2005/10/Process-20051014/tr.html#rec-advance, and the Working Group's expectations of the specifications under progress in the working group, we are recommending updating the milestone timetable in the charter as so (Timetable_11_2011.png):

[cid:image002.png@01CC9E30.E89AA710]
1Call for implementation takes us to Candidate Recommendation
2Assuming we have two interoperable implementations by this time.
3Assuming all spec updates are made this month.

5. Navigation Timing to Recommended
Considering Navigation Timing spec has been stable in CR for a long period of time, two interoperable implementations exist and we have a complete test suite, we need to determine the next steps in taking this spec to Recommended. The remaining work is to provide proof that our dependencies, WebIDL and HTML5, are stable or that the portions of these specs that we depend on are stable.

The Navigation Timing specification references the following specifications:
o WebIDL: Last Call since 09/27/2011
o HTML5: Last Call since 05/25/2011
o DOM 3 Core Specification: Recommendation
o Performance Timeline: Informative only. Spec is planned to be in CR stage this month.

As the HTML5 specification is very large and unlikely to reach Recommendation in the very near future, we will instead provide evidence that Navigation Timing dependencies are stable by showing that that portions of the HTML5 spec that Navigation Timing references haven't changed in a long time, and where they have changed, give test cases to prove our implementations match the HTML5 spec behavior.

The WebIDL specification is in its second Last Call phase. Per Cameron, editor of the WebIDL specification, this spec will not go to the Recommendation stage in the near future, as there are portions of the spec still under discussion. We may want to look use a similar approach with this spec as we are with the HTML5 spec, by proving sections referenced are stable. Philippe will investigate what needs to be done here.

DOM 3 Core Specification is already in the Recommendation phase.

Performance Timeline is referenced for informative purposes only. There are no explicit references to that specification.

Dependencies
Zhiheng took ACTION-51, http://www.w3.org/2010/webperf/track/actions/51, to look at the stability of Navigation Timing references. Zhiheng shared his findings here: http://lists.w3.org/Archives/Public/public-web-perf/2011Oct/0092.html:

Summary: No invalid/obsolete references have been found in the Navigation Timing spec and the risk of references becoming invalid or obsolete in the future is low.

Referenced Sections:
The following nine references to the HTML5 specification refer to concepts without depending on how they are processed.

The references listed below have not changed in the past year and no test cases are needed:

* prompt to unload: http://dev.w3.org/html5/spec/history.html#prompt-to-unload-a-document

* unload: http://dev.w3.org/html5/spec/history.html#unloading-documents

* HTTP redirects or equivalent: http://dev.w3.org/html5/spec/fetching-resources.html#concept-http-equivalent-codes

* HTTP GET or equivalent: http://dev.w3.org/html5/spec/fetching-resources.html#concept-http-equivalent-get

* (relevant) application caches: http://dev.w3.org/html5/spec/Overview.html#relevant-application-cache

* Fetch: http://dev.w3.org/html5/spec/fetching-resources.html#fetching-resources

* history traversal: http://dev.w3.org/html5/spec/Overview.html#traverse-the-history

* location.reload: http://dev.w3.org/html5/spec/Overview.html#dom-location-reload

The following reference needs to be updated:

* origin: http://dev.w3.org/html5/spec/origin-0.html#origin

The origin reference to HTML5 should instead be changed to The Web Origin Concept specification, http://tools.ietf.org/html/draft-ietf-websec-origin-06, which is more stable. ACTION 67: Update the origin reference in Navigation Timing to point to The Web Origin Concept specification on Zhiheng.

The following two references are related to the processing model:

* fetchStart

Step 6 of the Navigation Timing Processing Model, http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#processing-model, states: "immediately before a user agent checks with the relevant application cahces, record the current time as fetchStart." The HTML5 processing model for fetchStart has changed this year; however, the reference still remains valid as any further HTML5 fetchStart changes are unlikely to break the Navigation Timing implementation.

* document.readyState

The domLoading, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd and domComplete Navigation Timing attributes reference the HTML5 current document readiness definition, http://dev.w3.org/html5/spec/dom.html#current-document-readiness. This definition refers to the HTML5 document.readyState IDL attribute, whose definition has been updated in this last year. As Navigation Timing doesn't strictly depend on the document.readyState definition but instead on the definition of the current document readiness, a test case isn't strictly required here. However, as this is an easy test case to verify, Zhiheng will write a test to verify that the change in document.readyState does not impact the Navigation Timing implementation. ACTION 68: Write document.readyState test case to check impact to Navigation Timing on Zhiheng.

6. RequestAnimationFrame Open Issues
The following open issues are the only known remaining spec updates for the Timing control for script-based animations spec. These items have not been addressed since 5/18/2011. The working group has spent some time discussing each of these issues and has come to relative consensus on each one. We would the editors to review these issues, provide feedback and make the appropriate updates.

1. ISSUE-2: Callback time parameter needs definition

State: Open

Description: We need to decide what the time parameter passed in to callbacks actually represents -- the time at which the "sample all animations" algorithm starts, the time of the next display refresh, or something else.

Design Decision:
The working group feels the time parameter should be the time of the next frame. As developers will typically want to construct the next frame to be painted, this seems like the intuitive option. James or Cameron should also follow up with CSS animations and other animation specs and ensure this design is consistent with any similar concepts they may have.

2. ISSUE-3: Animation frame times should be monotonically increasing

State: Open

Description: Having animation frame times run off a monotonic clock would be better for authors than a clock that might jump backwards. Doing this argues for the reinclusion of the Window.animationStartTime attribute, so that scripts can avoid using Date.now() to record the animation start time, which might bear little relation to the monotonic clock values anyway.

Related emails:
1. [minutes] 20110727 Web Performance WG Teleconference #43<http://www.w3.org/mid/EE4C13A1D11CFA49A58343DE361B0B04068D9895%2540TK5EX14MBXC254.redmond.corp.microsoft.com> (from jmann@microsoft.com<mailto:jmann@microsoft.com> on 2011-07-27)
2. [RequestAnimationFrame] Summary of open issue status<http://www.w3.org/mid/CAD73mdLjMu5UyKQ9g3NgAWMP871LUTLM77jrAYszYwpQHGz4%252Bw%2540mail.gmail.com> (from jamesr@google.com<mailto:jamesr@google.com> on 2011-07-26)
3. [minutes] 20110720 Web Performance WG Teleconference #42<http://www.w3.org/mid/EE4C13A1D11CFA49A58343DE361B0B04068B7D6B%2540TK5EX14MBXC252.redmond.corp.microsoft.com> (from jmann@microsoft.com<mailto:jmann@microsoft.com> on 2011-07-20)
4. [minutes] 20110706 Web Performance WG Teleconference #40<http://www.w3.org/mid/EE4C13A1D11CFA49A58343DE361B0B04068B2197%2540TK5EX14MBXC252.redmond.corp.microsoft.com> (from jmann@microsoft.com<mailto:jmann@microsoft.com> on 2011-07-06)
5. [minutes] 20110629 Web Performance WG Teleconference #39<http://www.w3.org/mid/EE4C13A1D11CFA49A58343DE361B0B04068A5E01%2540TK5EX14MBXC252.redmond.corp.microsoft.com> (from jmann@microsoft.com<mailto:jmann@microsoft.com> on 2011-06-30)
6. RE: ISSUE-3 (monotonic-clock): Animation frame times should be monotonically increasing [Request Animation Frame]<http://www.w3.org/mid/F677C405AAD11B45963EEAE5202813BD19DE95ED%2540TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> (from Nic.Jansma@microsoft.com<mailto:Nic.Jansma@microsoft.com> on 2011-05-23)
7. Re: ISSUE-3 (monotonic-clock): Animation frame times should be monotonically increasing [Request Animation Frame]<http://www.w3.org/mid/BANLkTimVTQege%253DuodvH3oAiaWuuTf72_kA%2540mail.gmail.com> (from robert@ocallahan.org<mailto:robert@ocallahan.org> on 2011-05-23)
8. RE: ISSUE-3 (monotonic-clock): Animation frame times should be monotonically increasing [Request Animation Frame]<http://www.w3.org/mid/EE4C13A1D11CFA49A58343DE361B0B040683B3BB%2540TK5EX14MBXC252.redmond.corp.microsoft.com> (from jmann@microsoft.com<mailto:jmann@microsoft.com> on 2011-05-19)
9. Re: ISSUE-3 (monotonic-clock): Animation frame times should be monotonically increasing [Request Animation Frame]<http://www.w3.org/mid/BANLkTimQTKZhh2TKBG4DH6MSQVjAUBJ9Rg%2540mail.gmail.com> (from jamesr@google.com<mailto:jamesr@google.com> on 2011-05-18)
10. ISSUE-3 (monotonic-clock): Animation frame times should be monotonically increasing [Request Animation Frame]<http://www.w3.org/mid/E1QMp4R-0005Kc-LP%2540barney.w3.org> (from sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org> on 2011-05-18)

Design Decision:
The working group agrees its necessary to have a monotonic clock. Further, sub-millisecond resolution is necessary to get accurate frames per second measurement. To address these needs, the working group has recommended a High Resolution Time specification that will define a high precision sub-millisecond, monotonic clock that the Timing control, Timing specs and other specifications can reference. This specification should reference that spec, once it is written and consider this issue closed.

3. ISSUE-4: We perhaps should support an element parameter to requestAnimationFrame()

State: Open

Description: If we have this, we need to define which callbacks will get called and in what order. To handle callbacks causing elements to come in and out of view, we might need to iterate restyle/reflow and the running of callbacks. Robert proposed a processing model: http://www.w3.org/mid/BANLkTi=wNwcK6Xa4giD_Q3T-pP1GAszj_w@mail.gmail.com

Design Decision:
The working group does not want to include this feature at this time. If we do include this feature in the future, both the feature and the parameter should be optional. We may not want to make any text changes here, but if they editors want to clarify the expected behavior in the spec, they may choose to add a note in the spec.

4. ISSUE-5: Expected callback rates should be documented

State: Closed

Description: The spec should state that the expected callback rate when not throttling should match the display refresh rate, and that when we are throttling whether that means callbacks are deferred indefinitely or whether some other mode (fixed slow rate, exponential backoff) should be used.

Related notes:

Jatinder proposed some text: http://www.w3.org/mid/EE4C13A1D11CFA49A58343DE361B0B04068331C0@TK5EX14MBXC252.redmond.corp.microsoft.com

Cameron McCormack, 18 May 2011, 22:24:03

Fixed by http://dvcs.w3.org/hg/webperf/rev/8ca96303d8f5
James Robinson, 27 Jul 2011, 05:16:34

Design Decision:
Per feedback on the mailing list by jQuery, http://lists.w3.org/Archives/Public/public-web-perf/2011Aug/0046.html, we may want to improve the processing model to ensure a "warping" behavior where multiple callbacks are immediately fired upon return to visibility does not occur. We may want to add text to the processing model stating callbacks will not accumulate when the page is not visible and upon the document becoming visible, only a single callback should be fired per active animations.

5. New Performance Investments for this Working Group
As most of the Web Performance working group specifications are relatively stable, the working group is beginning to look at new performance areas to tackle next. The following specifications have been suggested:

1. High Resolution Time
The working group believes there is a need for a specification to define a monotonically increasing, high resolution time that can be used in the Timing specifications, requestAnimationFrame spec and any other specifications requiring higher resolution time. A high resolution time will help provide better latency and bandwidth measurements, for example. Further, this specification will also define a now() method that describes the time from the start of the navigation of the root document.

Jatinder was nominated to edit this specification and propose text. ACTION 69: Create High Resolution Time specification.

2. Background Activity
Most web pages today have been designed without the knowledge of the visibility state of a page; web developers have designed pages to act as if they are always visible. For example, animations may continue to animate in a background tab or a service may continue to work at full capacity on a background tab; both situations where a user cannot consume the information. Furthermore, about 25% of the top 100K webpages suffer from runaway timers - the timer continues firing even though the work is completed. These behaviors mean unnecessary higher resource utilization. As devices are becoming available in smaller mobile form factors, this higher resource utilization results in poor battery life.

Many mobile devices attempt to solve this problem by automatically throttling background activities. However, such behavior is not consistent across different platforms leaving an inconsistent experience for web developers. This specification will attempt to provide a standardized background activity throttling behavior.

Jatinder was nominated to edit this specification and propose text. ACTION 70: Share proposed Background Activity specification.

3. More Instrumentation / Timing APIs
There was discussion on having more detailed instrumentation/timing APIs that tools can hook into to give developers a more detailed view what the browser is doing from downloading resources to rendering the page.

Alois was nominated to propose use cases for such an API to the mailing list for further discussion. ACTION 71: Propose use cases for an Instrumentation/Timing API to be used for tooling purposes.

4. Memory Leaking and CPU Data APIs
There was discussion on having APIs that give information on potential memory leaks or CPU data to give developers a way to make their code more performant.

Arvind was nominated to propose use cases for such an API to the mailing list for further discussion. ACTION 72: Propose use cases for a Memory Leaking and CPU Data API.

5. Sending data back prior to an unload
Today, many analytics scripts will attempt to send back data on user behavior on a site upon the end of a user session. The end of a user session is conventionally defined as the moment the unload event is fired. In order to send this data up prior to losing the script context, many analytics libraries spin for about 500ms sending data back. This seems to be a very inefficient way to send data back prior to unload.

Jason was nominated to follow up on this topic and respond to the mailing list with ideas for further discussion. ACTION 73: Propose ideas on improving sending data prior to unload.

Attachments

image/png attachment: image001.png
image/png attachment: image002.png
image/png attachment: Timetabl_11_2011.png
image/png attachment: Timetable_4_2011.png

Received on Wednesday, 9 November 2011 00:39:44 UTC