[minutes] W3C Web Performance F2F Meeting 2012-11-09

W3C Web Performance F2F Meeting 11/09/2012

The W3C Web Performance working group members met face-to-face to discuss the charter for the working group's third chartered period. Here are the meeting minutes for the working group's discussions.


IRC log: http://www.w3.org/2012/11/09-webperf-irc



Meeting Minutes: http://www.w3.org/2012/11/09-webperf-minutes.html



Attendees

Jason Weber (Microsoft), Arvind James (Google), Jatinder Mann (Microsoft), James Simonsen (Google), Alois Reitbauer (Compuware), Philippe Le Hegaret (W3C), Paul Bakaus (Zynga)



Chairs
Jason Weber

Arvind Jain



Scribe

Jatinder Mann, Philippe Le Hegaret



Agenda

1.       Status of Current Specifications

2.       Survey Results

3.       New Charter

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



Meeting Summary

1.      Status of Current Specifications
The working group reviewed the status of all the current specifications being worked on in the working group.


-          Navigation Timing

The Navigation Timing specification has been in the Proposed Recommendation phase awaiting for its WebIDL dependency to reach Recommendation, before it could be standardized as a Recommendation. However, considering we have two browser vendors who Navigation Timing implementations pass a majority of the WebIDL tests (IE10 passes 75/81 tests and Firefox passes most as well), the working group is recommending we move this specification to Recommendation at the end of this month.


-          High Resolution Time

Considering there are three implementations of this API, test suite is complete and all implementations pass the tests, the working group recommends moving this specification to Recommendation at the end of this month.


-          Resource Timing

This specification is currently in the Candidate Recommendation phase. There is one implementation available in IE10 and Chrome is working on an implementation. Test updates need to be made.


There was a discussion on what the expected performance timeline should look like when two documents request the same resources. Opened ACTION-107- Follow up on the expected behavior when two documents request the same resource; how do the timelines look [on Jatinder Mann - due 2012-11-16].


-          User Timing

This specification is currently in the Candidate Recommendation phase. There is one implementation available in IE10 and Chrome is working on an implementation. Test updates have been made. There is no feedback on this specification.


-          Performance Timeline

This specification is currently in the Candidate Recommendation phase. There is one implementation available in IE10 and Chrome is working on an implementation. Test updates need to be made. There is no feedback on this specification.


-          RequestAnimationFrame

This specification has completed its Last Call. There remains the open discussion on whether to include window.animationStartTime in the specification. IE and Firefox implement window.animationStartTime (Firefox with a prefix, IE without a prefix).


-          Page Visibility

This specification is in the Candidate Recommendation phase. There are three implementation available of this interface (IE10, Chrome and Firefox) and a test suite. There has been one piece of feedback on clarifying the processing model text on pagehide/pageshow, which the editor will follow up on.


-          Efficient Script Yielding (setImmediate)

The working group wants to continue to include efficient script yielding in the next working group charter, so can continue working on this specification.

2.      Survey Results
As a part of the W3C Workshop for Performance survey, the working group asked performance experts and web developers their thoughts on the following six areas of investment: HAR format, memory measurements, network measurements, network streaming measurements, frame rate measurements and garbage collection interfaces. The working group received almost 400 responses to the survey. The results are displayed below, with rating 1 signifying most important, whereas rating 6 signifying least important.

Topics

Don't mind

Don't want

Rating 1

Rating 2

Rating
3

Rating 4

Rating 5

Rating 6

HTTP Archive (HAR) format

21.8%

1.8%

10.9%

11.7%

15.2%

13.7%

8.9%

16.0%

Memory Measurements

8.9%

0.3%

26.6%

21.8%

16.2%

13.2%

7.4%

5.6%

Network Measurements

7.4%

0.3%

20.6%

23.4%

21.3%

12.2%

9.9%

5.1%

Network Streaming Measurements

13.2%

0.8%

9.4%

12.4%

19.3%

18.8%

16.5%

9.6%

Frame rate Measurements

15.0%

0.8%

11.4%

17.0%

13.5%

15.5%

14.7%

12.2%

Garbage Collector API

14.2%

2.8%

21.8%

16.5%

10.2%

13.5%

9.1%

11.9%


3.      New Charter
For the past few months, the working group has been gathering information on which areas to focus our investment in the next chartered period by (A) inviting experts to the weekly conference calls, (B) asking performance experts and web developers to complete a performance survey, and (C) putting together a W3C Workshop for Performance, where performance experts were invited to present on problem areas and use cases.

Areas included in the Charter
Based on this information, the working group has decided to expand the charter to include the following areas:


-          Beacon API

Today, analytics scripts will block the current page from unloading by running in a loop in order to send analytics data to a web server. This behavior causes the perception of poor performance, as it appears the navigation is delayed. A beacon API would send data back to a server without waiting for a response that the data has been sent. It would be a fire and forget model; the browser makes the promise that there data will be sent to the server.



Alois and Jatinder will explore this area and co-edit the specification.

-          Diagnostics Interfaces

Instead of providing information on all browser diagnostics and resources, capturing of which may have a performance impact and may not be actionable for developers, the working group instead would like to focus on providing scoped and actionable diagnostics data for web developers.



The working group would like to expand the charter to focus on (A) providing data on memory leaks to web developers and (B) interfaces that provide error logging and availability information in a manner analogous to the performance timing interfaces.



Alois and Jatinder will explore this area and co-edit the specifications.


-          Resource Priorities

Today, web browsers download resources in priority order that they believe are most efficient in helping the page load. Though, there are existing concepts of "defer" and "async" downloading of certain resources, this concept has not been expanded to all resources. The working group would like to expand the charter to consider areas where developers can give hints to the browser to consider the priority in which resources should be downloaded.



Jatinder will explore this area and edit the specification.



-          Prerender

Chrome today supports a prerender feature that allows navigations to appear almost "instantly" in cases where it has high confidence that a user will visit an URL.  The browser will proactively navigate to a web page in a hidden tab, when it sees the link type "prerender" or has high confidence that user will visit that link. When the user does visit that link, the browser will make the hidden tab visible, giving the perception of instant navigation.



The working group would like to expand the charter to standardize the prerender feature.



Arvind will explore this area and edit the specification.



-          Timing Interfaces

The working group would like to continue working on the second versions of the Timing interfaces, Navigation Timing, Resource Timing, User Timing and Performance Timeline. This will include providing web workers support in the Timing interfaces and providing video byte ranges in Resource Timing.



Jatinder and Arvind will continue to edit the Timing specifications.



-          setImmediate/Power

The working group would like to continue working on providing power- and CPU-efficient APIs, like the Efficient Script Yielding (setImmediate) interface. The working group would also like to look into new areas of making power improvements.



Jatinder and Jason will continue to edit the setImmediate specification.



-          Display Performance

The working group would like to expand the charter to work on providing additional information to web developers on the frame rate / throughput information of the display.



Jason will explore this area and edit the specification.


Interesting Areas for other Working Groups
The working group found the following areas to be interesting, but out of scope for this working group. The working group will share these ideas with other working groups:


-          Client-Hints (IETF or DAP)

-          Delta Delivery (IETF)

-          Device Capabilities (DAP)

-          Runtime Video Performance Metrics (WebRTC, HTML)

-          Performance Best Practices (Webplatform.org)


Areas the Working Group is not interested in
The working group does not want to pursue the following areas in this chartered period:


-          Timing in HTTP Header

Considering there is a performance risk of increasing the size of the HTTP header, this work will require collaboration with IETF which may not happen until after HTTP2.0 and the data is already currently available to JavaScript, the working group doesn't want to focus on this area in this chartered period.



-          Memory Heap

Most memory information is not really useful to developers, as it may include total system memory (and developers don't know what other applications are running at that time) and different machines have different characteristics. We believe that providing memory leak information here will be more useful to web developers.



-          Garbage Collection API

Most web developers may find manual garbage collection a difficult to manage and may not chose the most optimal path. This seems like an area where the browser should continue to manage.



-          Background Throttling

Browsers are already throttling down timer activity, releasing memory, and other activities to save resource consumption in background tabs. As there are no web platform APIs proposed here, there is no need to specify a standard here.



-          Idleness

Providing CPU idle information to web developers will not help developers make the system more efficient (by triggering an event on system idle, we will actually break the system idle at that point). APIs like Page Visibility are better manage power- and CPU-efficiency by allowing developers to throttle activity when the user cannot see the page.



-          Above the Fold

Providing timing on when the page painted above the fold is a difficult problem to solve from the user agent point of view; it's hard to specify the moment when the page is above the fold, as the first paint may or may not be painting above the fold.




Meeting Minutes

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



<trackbot> Date: 09 November 2012

http://w3c-test.org/webperf/tests/submission/W3C/NavigationTiming/nt-idlharness.html
Navigation Timing Status

plh: Running with these tests, IE10 passes 75/81 tests and Firefox passes most as well. I recommend we speak with the Director to move Navigation Timing to Recommendation.

https: //w3c-test.org/webperf/tests/submission/W3C/HighResolutionTime/hrt-idlharness.html
... //w3c-test.org/webperf/tests/submission/W3C/ResourceTiming/rt-idlharness.html
Resource Timing

<JatinderMann> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html

<JatinderMann> James: We should update "This section is non-normative." text in Navigation and Resource Timing to "This illustration is non-normative."

<scribe> done

<JatinderMann> ACTION Jatinder Follow up on the expected behavior when two documents request the same resource; how do the timelines look

<trackbot> Created ACTION-107 - Follow up on the expected behavior when two documents request the same resource; how do the timelines look [on Jatinder Mann - due 2012-11-16].
RequestAnimationFrame

<JatinderMann> https://developer.mozilla.org/en-US/docs/DOM/window.mozAnimationStartTime

<JatinderMann> Jatinder: Both IE and Firefox implement window.animationStartTime (Firefox with prefix). I'll follow up the Editor's to close on this.

http://w3c-test.org/webperf/tests/submission/Intel/user-timing/
Next charter

<scribe> scribeNick: plh

https: //www.w3.org/2002/09/wbs/1/webperf2012/?login

for HAR, Arvind will keep thinking about it

James: for memory mangement, we have some privacy concern
... ie can figure if someone is logged in into a service based on heapsize
... ie you put the service into an iframe, then look at the heapsize

Alois: you can ask for user permission

James: they wouldn't know what the question meant...

Jason: I'd like to do something related to memory
... ie offering reclaim pattern
... ie a memory usage pattern where the runtime monitors resources and efficiencly garbage it

Alois: but you'll want to know if you're leaking memory or not

Jason: a dev shoulnd't have to worry about memory

Alois: but we make bugs, I'd like to know if I'm retaining a reference

James: would help to break this into use cases

Jatinder: let's going through the survey results
... adaptive sreaming api...
... people just want to know what
... connection is used

http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

Jatinder: Resource Timing 2 needs to cover video as a post processing timing measurements
... above the fold
... Frame rate
... AnimationStartTime
... <video?
... setImmediate
... Memory: GC, info, leak, profiling

http://www.ietf.org/rfc/rfc3229.txt

we're classifying things into four buckets for the next charter

In: Beacon (ie send me those stuff when you have time)

Toss the ball: Client Hints

Out means "drop it"

Toss the ball means "find someone else to do it"

Toss the Ball: Client Hints, Delta Delivery

Out: Timings in Header

In: Diagnostics (Leaks, Errors, etc.)

<pbakaus> plh, where are Client Hints going to be tossed to? IETF?

we didn't talk about it further.

<pbakaus> ok thanks

IETF yes

DAP maybe

Delta Delivery seems clearly in IETF to me

<pbakaus> yes, agreed

Out: GC

<pbakaus> Sad about GC, but all things asset memory are more important to us.

Toss the ball: device capability: CPU, Memory size, etc.

Out: Memory Heap

<Alois> but part of heap diag

In: Resource Priority

Out: background throlling
... Idleness

Maybe: HAR

https: //support.google.com/analytics/bin/answer.py?hl=en&answer=1008080

http://www.w3.org/TR/html5/links.html#link-type-prefetch

In: Pre-render

Out: Above the fold

In: Display Perf

<pbakaus> plh, what is Display Perf referring to?

framerate, throughput

Toss the ball: Realtime Video/Streaming Perf

In: Resource Timing 2 (ie postprocessing)

http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0239.html

*.toJSON to be considered in our specs

(we're now talking about setImmediate)

In: setImmediate/Power

In: Timing in Web Workers

Maybe: Async scroll

Toss the ball: Best Practices (Steve)

Out

In

Maybe

Toss the ball

Timing in HTTP Header

Beacon - Alois/Jatinder

HAR - Arvind?

Client-Hints (IETF?, DAP?)

Memory Heap

Diagnostics (Leaks, Errors) - Alois/Jatinder

async scroll - James?

Delta Delivery (IETF?)

GC

Resource Priorities - Jatinder

Device Capabilities (GPU, CPU, Network, etc.) (DAP?)

Background throlling

Pre-render  (link rel=prerender) - Arvind

Video/Streaming perf (WebRTC?, HTML?)

Idleness

Display perf  (framerate/throughput on the glass)- Jason

Guidelines -> Steve (webplatform.org?)

Above The Fold

Resource Timing 2, ie media postprocessing timing - Arvind


setImmediate/Power - Jason


Timing in Web Workers - Jatinder


Action Items [End of minutes]