W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2010

[minutes] 20101215 Web Performance WG

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>
Message-ID: <1292966643.2414.8.camel@chacal>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:29 UTC