[minutes] Web Performance WG Teleconference #119 2013-09-11

Meeting Summary:



1.     User Timing Issue

The issue raised here, http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0001.html, doesn't seem like it is a blocking issue, as a developer can easily work around it. We'll follow up on the mailing list.



2.     Defining an originTime for performance.now()

We need to define an originTime value that describes the time value from which the performance.now() time is measured. This will help developers compare when an event occurs in a shared web worker relative to the document. We need to decide whether we will use unix epoch as the origin for originTime, or another reference point in time like the point when the browser was launched. To be useful, the origin of originTime must be before the start of navigation of any document that is using the shared worker.



3.     Resource Priorities open issues

The working group discussed and closed on a few resource priorities open issues. We will respond to the mailing list threads directly.



4.     Prefixes in Test Cases

The working group should either include all browser vendor prefixes in its feature detection logic in the test cases or not use prefixes at all in test cases.




W3C Web Performance WG Teleconference #119 2013-09-11





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



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



Attendees

Jatinder Mann, Daniel Austin, James Simonsen, Rob Dickenson


Scribe

Jatinder Mann



Agenda

1.     Discuss User Timing open issue

2.     Discuss originTime in performance.now() spec

3.     Discuss Resource Priorities

4.     Discuss time slot for conference call

5.     Discuss prefixing

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



Minutes:
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 received, 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 accommodates people interested in those topics. Since Alois isn't on the call today, let's defer to the mailing list.