<trackbot> Date: 11 September 2013

<RobDickinsonFromDell> Hellow

User Timing Open Issue

http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0001.html

Jatinder: Based on the example, a simple workaround for async function may just be to take a performance.measure('name'), and not pass in a start mark. That way you will get the time from navigationStart until the async call has been made. If one really desires to see the deltas, you can always subtract the measure's duration from the mark's duration.
... Also, I wasn't able to reproduce the issue Kiran saw with the code he had submitted on either Chrome or IE. I think it's worthwhile to ask him to share a repro test case.

James: My interpretation was that this was just something people can fall for.

Jatinder: I don't think we should take this change.

originTime in performance.now() spec

Jatinder: Goal was if developers ever wanted to compare the absolute times of two different performance.now() measurements, they could just add performance.originTime to the performance.now() value. This makes comparing an absolute time value from a shared worker context with a dedicated worker or top level document possible.
... To make this work, performance.originTime must be in milliseconds from unix epoch in at least microsecond resolution, monotonically increasing. I think this should be possible with doubles.

James: Seems like you want to compare when a worker sent data and when it was recieved, so you can figure out the latency.
... We should consider coming up with a new point in reference, just has to be before the first navigation start. E.g., start of browser launch.

Resource Priorities

http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0042.html

Jatinder: Should we mark the lazyload behavior with a MUST clause? I was hoping by letting the user agent decide what is network contention we can still have some wiggle room. E.g., for testing, you just need to create a page that uses up all six available connections (for some user agents), and then try to download another resource. The next resource should be a non-lazyloaded resource. I'm not against moving this back to a MAY clause.

James: I am leaning towards MAY, but I recognize that it may make testing harder.

http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0039.html

Jatinder: I think there is value in the Web Perf WG specing and defining the meanings of the lazyload and postpone attributes in a Resource Priorities spec. As the two attributes only apply to some elements, we will need to define which attributes support lazyload or postpone. Should we define those in this spec or in HTML5?

James: As long as its defined correctly, I don't care where it goes. I think we should let Philippe and others figure that out.

Daniel: Should we bring this up with HTML WG?

Jatinder: I think we should finish defining the interface and make sure it meets our performance goals. At that point we can decide if we want to keep it in this spec or not, which I would like to unless there is a technical reason we can't, then we should follow up with HTML.

http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0016.html

Jatinder: Should postpone and lazyload not block the DOMContentLoaded event? Should it also not block the document readiness states? Seems like that should be the case.

James: Yes, seems like we should keep not block those events either.

Jatinder: We will want to make sure we don't mess up the ordering of events, so I think its logical to not block either DOMContentLoaded or document readiness states.

Use of prefixes in tests

http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0043.html

Jatinder: I think our goal should be to either not use prefixes in test cases at all or include all vendor prefixes in our test cases. For now, User Timing can remove the prefixes entirely from the test cases, as we now have two implementations without prefixes. What are your thoughts on future prefixing?

James: We should probably removing the prefixing code from the User Timing test cases.

Jatinder: Yes, let's do that for now. If we do add prefixing in the future, it should cover all vendors.

Conference call time slots

Jatinder: Mark from Akamai is interested in joining the conversation on wire protocol and JS injection. He's in Melbourne. Since we have active members from Seattle, San Fran, Boston, Vienna, the only time slot that seems to work for all is 1PM PST (1PM San Francisco, 4PM Boston, 10PM Vienna, 6AM Melbourne). See http://www.timeanddate.com/worldclock/meetingtime.html?iso=20131113&p1=224&p2=43&p3=259&p4=152&p5=33
... We may want to create a seperate time slot for the JS Inspection and wire protocol discussions, if that accomodates people interested in those topics. Since Alois isn't on the call today, let's defer to the mailing list.

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: JatinderMann
Inferring Scribes: JatinderMann
Present: Daniel Rob Jatinder simonjam

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 11 Sep 2013
Guessing minutes URL: http://www.w3.org/2013/09/11-webperf-minutes.html
People with action items: