[minutes] 20110209 Web Performance WG

Web Performance Working Group
09 Feb 2011

See also: IRC log<http://www.w3.org/2011/02/09-webperf-irc>

Minutes
http://www.w3.org/2011/02/09-webperf-minutes.html
Attendees
Present
Anderson, NicJansma, TonyG, Zhiheng, SteveSouders
Regrets
Chair
AndersonQuach
Scribe
AndersonQuach
Contents

  *   Topics<http://www.w3.org/2011/02/09-webperf-minutes.html#agenda>
     *   User Timings<http://www.w3.org/2011/02/09-webperf-minutes.html#item01>
     *   Finalizing the timeline of Navigation Timing and getting to Candidate Recommendation.<http://www.w3.org/2011/02/09-webperf-minutes.html#item02>
     *   Summary<http://www.w3.org/2011/02/09-webperf-minutes.html#item03>

         i.            Anderson will Update UserTiming to use type Array instead of PerformanceAssociativeMarkList. And update mark method, should note that it's of 1ms or high resolution.

        ii.            CR Review and proposed recommendation feedback, processing model, security and privacy to discuss on 2/16

      iii.            Flush out standard marks, their definitions and measures, the start-stop times.

      iv.            Update domComplete, loadEventStart, loadEventEnd, domContentLoadedStart, domContentLoadedEnd to take the time stamp of when the event first fired.

________________________________
User Timings

Tony: having arrays instead of list would be better btw

Steve: is there any discussion on measures?

Anderson: we discussed that in the past, either within the standard or as best practices. like in a library. we felt like having the measures there was icing on a cake, ie not a requirement

SteveSouders: Measures have key and values, key the name and the values is the delta. Every framework and look at the measures way to consume it in a standard way.
... Be able to see the phases overlayed overtop of HTTP requests. If it's not in a standard array, dev tools and analytics will not be able to readily access the phases.
... In Web 1.0 we used to be able to use Done, but in Web 2.0, we'll have to use visual indicators, sending waiting for, spinning cursors and etc. If we had measures with standard names, when that measurement was set the browser would say done in the status bar.

TonyG: The idea is that we standardized Marks themselves, such as mark fullyLoaded. The question marks versus measures, do we allow the page to say mark a time here, or does a web developer say start/stop time.
... As we went thru Nav Timing, not everything has a complete pair of start-stop pairs. Marks seem much more general and having measures on top of that may not have additional value.
... Is the format a single time or a start-stop was the question we asked ourselves.

SteveSouders: Certainly we want to do marks. Certainly marks have a paired start and end. In a page you may have 5-25 marks and web developers may face ambiguity with custom markers.
... Going to have write logic for Pingdom, Gomez, Keynote. Otherwise standardizing the phases, the consumer of these marks can be ignorant of custom markers.

TonyG: There's cost to maint. code bloat to the API surface. We need to be careful about what we add. I wanted to expose the simplest set of tools to build this functionality. I didn't want to build application logic into the platform.
... We want a simple way to mark with a high performance counter at a given time and a standard place to get those marks. Additional logic can be considered application logic.

SteveSouders: If we don't have measures, frameworks will quickly write measures library and we won't have industry standards. These frameworks, dev tools and metric companies may not be able to come with their own representation.

TonyG: What are your thoughts Nic and Anderson?

NicJ: We like the idea when we designed it we had Marks and Measures in PPB6 and even in the IE9 Beta before removing it to conform with Navigation Timing.
... We agree with the benefits of standardization and mitigating fragmentation. We can provide some sort of standardized Library, I don't know if that would be enough of a standardized.
... We leaned towards efficiency and shipping on time.

AndersonQuach: We need to flush out the marks and phases to help web developers use standardized markers like fullyLoaded, aboveTheFold, interactive, and visible.

SteveSouders: Definitely a lot of details need to be flushed out, how do we guide developers with the scenarios with a send email phase, with a corresponding start and end times.

Finalizing the timeline of Navigation Timing and getting to Candidate Recommendation.

AndersonQuach: I wanted to touch base on what we do for in document mark-up replacement.

TonyG: It's described in the domComplete attribute where only the first time the event fired.

NicJ: We need to add it to domContetLoaded and loadEvent.

<plh> If the current document readiness changes to the same state multiple times, domLoading, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd and domComplete must return the time of the first occurrence of the corresponding document readiness change.

plh: [prior in the call] we need at least two implementations to move PR. We could do more but it's up to us. Since we have experience in mozilla, ie, and webkit engine, it doesn't seem we would gain much in waiting. and nothing prevent us from doing a navigation timing 2.0 if we want to. for CR, we need Zhiheng to make his latest editorial changes and we can then decide to move to CR for the duration of CR, it's also up to us. We need to have the tests and implementation report to move out of it. We could skip CR if we have those already btw

Summary

i. Anderson will Update UserTiming to use type Array instead of PerformanceAssociativeMarkList.

ii. Update mark method, should note that it's of 1ms or high resolution.

iii. CR Review and proposed recommendation feedback, processing model, security and privacy to discuss on 2/16

iv. Flush out standard marks, their definitions and measures, the start-stop times.

v. Update domComplete, loadEventStart, loadEventEnd, domContentLoadedStart, domContentLoadedEnd to take the time stamp of when the event first fired.