See also: IRC log
trackbot, start telecon
<trackbot> Date: 26 September 2012
<trackbot> Meeting: Web Performance Working Group Teleconference
<trackbot> Date: 26 September 2012
<mnot> sorry, someone just rebooted our phone; sec
<plh> mnot? how's the phone? still rebooting?
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 standarize that. Or
we can standarize 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 seperate 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. Realisitically, 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.
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.
<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.
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 explictly call the expected behavior for shared workers or call them out of scope.
Tony: I'm not sure if will even be techincally 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.
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ITF/IETF/g No ScribeNick specified. Guessing ScribeNick: JatinderMann Inferring Scribes: JatinderMann Default Present: +1.617.444.aaaa, Plh, mnot, +1.650.214.aabb, Tony, Will, Mark?, Alois, [Microsoft], Arvind Present: +1.617.444.aaaa Plh mnot +1.650.214.aabb Tony Will Mark? Alois [Microsoft] Arvind Jatinder plh TonyG tobie simonjam WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 26 Sep 2012 Guessing minutes URL: http://www.w3.org/2012/09/26-webperf-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]