[minutes] 2012-09-26 Web Performance WG Teleconference #83

Meeting Summary:



1.       Networking Improvements

Mark Nottingham from Akamai joined us today to discuss ideas to help drive network performance improvements.



One task Mark is interested in is finding ways to prove that HTTP 2.0 will have the performance benefits that it is trying to achieve. Whether this is through browser vendor studies or standardized Web Perf APIs is to be determined. Mark will submit more detailed asks to the Web Perf mailing list.



Mark would also like the Web Perf WG to review his paper on HTTP Browser Hints, http://tools.ietf.org/html/draft-nottingham-http-browser-hints-03. The proposal makes it possible for web servers and browsers to potentially improve performance in some situations. Mark intends to update this proposal and will share those updates with the Web Perf mailing list.



Mark reports that Akamai internally uses the Navigation Timing interface for their own performance measurements. As we are now working on Navigation Timing 2, we have asked Mark to follow up with any feedback that Akamai may have for this spec. He will follow up on the mailing list.



2.       Call for Participation

Please forward widely the Web Perf WG Call for Participation in our Workshop, http://www.w3.org/2012/11/performance-workshop/, and our performance investments survey, http://www.w3.org/2002/09/wbs/1/webperf2012/. We will officially send a mail with the call for participation to the Web Perf mailing list that can be forwarded.



3.       Test Cases

Philippe and Tony have submitted the following three test cases that test the Candidate Recommendation version of the High Resolution Time spec. Google and Microsoft are planning on reviewing these tests this week before we move them to the approved folder next week.

-          http://w3c-test.org/webperf/tests/submission/Google/HighResolutionTime/test_cross_frame_start.html

-          http://w3c-test.org/webperf/tests/submission/W3C/HighResolutionTime/basic.html

-          http://w3c-test.org/webperf/tests/submission/W3C/HighResolutionTime/monotonic-clock.html



4.       Web Worker Support

The WG feels that the performance.now() function should be made available to Web Workers. Whether this will come as an update to the current High Resolution Time spec or in the next version is yet to be decided.



The WG also wanted to discuss whether the Timing interfaces should also be made available to Web Workers. From a tooling point of view, it may be interested to gather Timing data from a background worker thread. However, we need to determine if there are any restrictions on Web Workers that will make this not possible. Additionally if we are to support Timing in Web Workers, we will need to define the expected behavior for the shared worker case. This work, if taken, will be done in the Navigation Timing 2 spec.




Detailed Notes:



Web Perf Teleconference #83 9/26/2012



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



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



Attendees

Present for Navigation Timing, Resource Timing and User Timing (4-5PM EST/1-2PM PST)

Jatinder Mann, Philippe Le Hegaret, Alois Reitbauer, Tony Gentilcore, Arvind Jain, James Simonsen, Tobie Langel, Mark Nottingham


Present for Page Visibility, Efficient Script Yielding, Display Paint Notifications (4-5PM EST/2-3PM PST)

Meeting cancelled.



Scribe

Jatinder Mann



Contents

Agenda

1.       Mark Nottingham (Akamai) to discuss potential new network performance ideas

2.       F2F and Workshop details

3.       Test Cases

4.       Web Worker Support

--------------------------------------------------------------------------------
Network Improvements



Mark: We would like to understand metrics taken from http 2.0 and see proof that there are real performance improvements in real use cases.
... It could be that we can get a lot of that information out of the Timing specs, or it could be that we could look at improving the Timing specs based on the http 2.0 updates.

Matt: For example, how multiplexing is used. Memory compression, etc. Might be interesting for some people to get TCP information from client.

Will: I would love to see the data and compare with SPDY.

Arvind: We currently do have Navigation, Resource and User Timing. But we don't have memory usage measurements today. These can be considered in new specs, but not sure how to proceed though. If there is something you would really like to see us measure, please put that on the mailing list and we can spec it accordingly.

Mark: While we are working on http 2.0, we would like to see feedback on the changes we have made. We will need to work with browser vendors to get that data, but it may be that we do not need to standardize that. Or we can standardize it if we think it's the right thing to do.
... The other aspect of things that might be interested to talk about is that I have a draft out of HTTP 2.0 Browser Hints. On how the browser can use these hints to make improvements. Everyone from a website or CDN gets really excited about, but all the browser people I talk to about are a bit more skeptical that it needs to be thought about it more.

Arvind: Is that an IETF draft?

Mark: It's just a document that happens to be on the IETF. I've made some more revisions to make it more practical. My overall interest is that there is a back channel between web servers and browsers to make sure you do the more performant action.

<tonyg> Proposal: http://tools.ietf.org/html/draft-nottingham-http-browser-hints-03

Tony: I'm curious what you think is the killer app here? As I understand there is a separate manifest file, which will have overhead.

Mark: Different folks have different interest. Smaller headers is interesting to some folks. DNS hint or a very small header to notify the browser that hints are available to the site is something I want to add. Realistically, I doubt every site will use this on the internet.
... If I have it my way, there won't be a DNS option.

Plh: Mark, yesterday you were mentioning that Akamai is using Navigation Timing, that's great.

Mark: Yes, we are internally.

<plh> http://www.w3.org/wiki/Web_Performance/Publications

<plh> http://w3c-test.org/webperf/specs/NavigationTiming2/

Plh: If you have any suggestions on how to improve Navigation Timing, please do make those suggestions as we are working on the next version of the spec.

Mark: We will follow up and get back to you on the mailing list.
Web Perf Workshop

http://www.w3.org/2012/11/performance-workshop/

Plh: I have drafted a call for participation document.

<plh> http://w3c-test.org/webperf/tests/submission/Google/HighResolutionTime/test_cross_frame_start.html

Jatinder: We should share this paricipation document with the Web Perf WG.

Plh: I'll get that out soon.
Test Cases

<plh> http://w3c-test.org/webperf/tests/submission/W3C/HighResolutionTime/basic.html

<plh> http://w3c-test.org/webperf/tests/submission/W3C/HighResolutionTime/monotonic-clock.html

Tony: I have updated the test_cross_frame_start.html test to match the spec.

Plh: I have updated two tests. Can Microsoft and Google review these tests?

Jatinder: I will review these this week.
Web Workers Support

Jatinder: There was a discussion on the mailing list on whether we should support the High Resolution Time now() method in Web Workers. I think there is no reason that context shouldn't get the High Res Time. There was also a mention of whether now() should live on 'self' and not 'performance'. I disagree with that approach as it will cause confusion and make it hard to port code to workers.

Tony: I agree with making performance.now() available in workers.

Jatinder: There was also a mention of whether or not we want to make the Timing methods and properties on 'performance' also available on workers.

Alois: From a tooling point of view, if they are available, we would want to use a worker background thread to gather the Timing data rather than using a foreground ui thread.

Jatinder: The spec will need to explicitly call the expected behavior for shared workers or call them out of scope.

Tony: I'm not sure if will even be technically possible to make Timing data available to the worker due to constrains in the worker spec. I need to review this in more detail.

plh: This sounds like details that should be covered in the Navigation Timing 2 spec.

Jatinder: Agreed. I will send mail out thoughts to the mailing list. We can continue the discussion there.