- From: Philippe Le Hegaret <plh@w3.org>
- Date: Tue, 21 Dec 2010 16:24:03 -0500
- To: public-web-perf <public-web-perf@w3.org>
Available at
http://www.w3.org/2010/12/15-webperf-minutes.html
Text version:
Web Performance Working Group Meeting #14
15 Dec 2010
Attendees
Present
AndersonQuach, JamesSimonsen, Plh, TonyG, Zhiheng,
[Microsoft], plh, JasonWeber, NicJansma, KarenAnderson
Regrets
Chair
JasonWeber
Scribe
AndersonQuach
Contents
* [2]Topics
1. [3]Navigation timing feedback on window.performance, DOM
readiness markers.
2. [4]Review new test cases.
* [5]Summary of Action Items
_________________________________________________________
Navigation timing feedback on window.performance, DOM readiness
markers.
TonyG: If we get site compat issues filed, we can move to an
interface that is read-write.
PLH: we should capture this in the spec before last call.
[6]http://www.w3.org/TR/html5/the-end.html
[6] http://www.w3.org/TR/html5/the-end.html
AndersonQuach: Recommend that we keep the markers as specified in
the Navigation Timing specs, for the points Nic mentions in mail.
NicJansma: Web developers can add a callback to the onreadystate
event to do work.
TonyG: Multiple scripts may be adding listeners, the site author may
not understand all the listeners attached and the performance
impact.
JamesSimonsen: We brought this up, there's a lot of info and
technical. The distinct of the DOM readiness state. I expect stuff
user-agent authors understand. Would like to steer them into a
direction that is self documenting and succint.
TonyG: There are points i didn't considered, there are differences
between each of these marks. Maybe it's worth having them.
AndersonQuach: Each marker was introduced that have scenarios where
site developers can operate on them.
NicJansma: A good deliverable are samples and best practices on how
to use these events, to help increase the awareness of the
individual markers.
Zhiheng: I like the way the spec is now, it captures the critical
path of a page load.
<plh> --> [7]http://test.w3.org/webperf/tests/submission/Microsoft/
tests from MSFT
[7] http://test.w3.org/webperf/tests/submission/Microsoft/
Review new test cases.
NicJansma: We would like feedback on the tests, particularly for
user interactions.
KarenAnderson: Document reload, is it okay to have a test that
requires interaction, e.g. navigation_type_reload.htm?
plh: Yes, I would think so. Unless we can find a way to do it
automatically.
TonyG: in that example, can you call window.location.reload
NicJansma: It's more of a general question about user-interactive
test cases or tests that require user interaction.
... It could be structured as a start page and move to a landing
page.
plh: General guideline is that automatic is preferred.
... We prefer automatic tests, once potentially talk about 100k +
tests when more tests are added. For example: Mozilla would be
reluctant if the tests are manual.
NicJansma: We agree, we should automate as much as possible.
Zhiheng: We have more than 10 test cases now. How do we have
agreement on approved tests.
AndersonQuach: As long as we have two user-agent vendors review and
are okay we can approve it.
plh: important to record that we approve the tests
... or remove a test to remove the test from the approved section
... as long as we make it clear to add the test or remove the tests,
as long as someone is going to do it we'll be fine.
... what about last call?
Zhiheng: namespace change to keep as read-only or read-write for
window.performance.
JasonWeber: Would like to ship a standards compliant implementation
in IE. Would like to make a call for performance and not change the
spec.
... Would like to finalize on the spec and remove uncertainty. we're
open to either solution, read-only or read-write.
... We want to make sure there is integrity in the data.
... If we open up the performance object and someone can overwrite
timing or navigation underneath.
TonyG: We have one more idea. We can try to get some data on a
million sites.
JasonWeber: TonyG have you seen our data. I was satisfied with that
personally, there is some feeling we want more confidence that it
won't introduce compat issues.
JamesSimonsen: The safest way to go is go with read-write and
reduces the chances existing sites would break.
JasonWeber: From our release process we are not comfortable with the
ambiguity in the spec, or the possibility of a fallback, we would
leave a vendor prefix.
Received on Tuesday, 21 December 2010 21:24:10 UTC